Well, then my powers are all. Ie, please tell me how to write your first test, what is there anyway?

Answer 1, Authority 100%

It’s time to update the answer. The original version can be seen down.

CodeCeption

PHPUNIT does not affect anywhere, but no application is able to survive only by UNIT tests. Over time, it appeared CodeCeption , which is a big superstructure over PHPUnit, Selenium And also heaps of packages, in which I myself did not look. CodeCeption provides three types of testing:

• Acceptance – “Acceptance” Testing, checking the user with scripting-based applications (BDD).
• Functional – functional testing, functional verification of the application.
• unit – modular testing, low-level testing of specific functions.

Unit Testing

with modular testing is the easiest way to check specific functions: Create an array of data from what should go to the input and what should happen at the output, then we run through this data and see if everything turned out as you wanted. Modular testing is not limited only to it, but it is calculated on checking individual functions, methods and modules, accurate verification of output with the required, check states of the same modules.

Functional Testing

Functional testing appeared when it became clear that in addition to checking the functions, it was necessary to check the application that it does not produce 404 for existing data, it issues 403 for closed sections, issues 400 on incorrectly entered data. Functional testing gradually developed – the response codes of the response codes, and developers are interested in obtaining a user of this or that information on the page. Here, there was such a thing as Selenium – a server that allows you to run the browser and interact with it, and WebSpider is the emulation of the browser, which also allows you to “go through”.

Acceptance Testing

CodeCeption The same reformatted the concept of functional testing and entered Acceptance Testing. In CodeCeption, functional testing is testing pages through a web-spider, Acceptance Testing – Testing pages through a browser. Formally, these tests may match up to the class name, but Acceptance testing is able to check the real visibility of HTML elements on the page and track the job JavaScript.

Yii of the first version existed in the separation from general standards in favor of ease of use (although, frankly, I do not know whether the standards were then). Yii 2 also came to Neumpeits, and to abundant use of other people’s packages, including CodeCeption. CodeCeption is put in the same way as all other dependencies of Yii – through Composer

How to use CodeCeption?

CodeCeption, like most modern packages, offers to work with it through the command line. Main executable File – App_dir / Vendor / CodeCeption / CodeCeption / CodeCept ,
For convenience, I will write just CodeCept . The easiest way to install CodeCeption is globally and configure the alias command to an appropriate file.

First you need to productize the application:

CodeCept Bootstrap

This will create the Tests folder and create inside the entire necessary infrastructure. In the examples of Yii it will already be done.
After that, you need to configure CodeCeption using YAML files in Tests, but it is better to watch immediately in the documentation .

CodeCeption provides the ability to write tests as based on phpUnit_framework_testcase (Ctestcase from Yii 1. He was wrapped around it), and on the basis of its wrapper \ CodeCeption \ Testcase \ Test . Create a test is the easiest way again from the console (suppose that the test is created for the module httprequest )

CodeCept Generate: Test Unit httprequest
// Test Was Created in% App.Root% / Tests / Unit / httprequesttest.php

CodeCeption itself adds the Suffix Test (which allows you to separate test classes) and the extension .php .
Since most likely there will be many tests, you can immediately specify the folder where the test should be labeled. Suppose, the full name httprequest is actually \ core \ http \ httprequest and it is lying in the % app.root% / core / http folder Then it will be reasonable to put the test in the % app.root% / tests / core / http :

CodeCept Generate: Test Unit Core / http / httprequest
// Test Was Created in% App.root% / Tests / Unit / Core / http / httprequesttest.php

Fine, what should I write in this file now?

Inside the file is a test class. This class is a set of test methods that check the behavior of the code, and additional infrastructure methods.
Each method-test starts with the test prefix, testvalidate ; a good tone will substitute the name of the tested method after the prefix if only one method is checked in the test). PHPUnit pursuant class and detects all methods starting with this prefix, and then run one by one. Each test method checks the code of code using assert PHPUNIT methods , each such method checks the data obtained. For example, $ this- & gt; AssertTrue ($ httprequest- & gt; ispostrequest); check if True corresponds to $ httprequest- & gt; Ispostrequest , and in case the verification Fall, the test will fail (ie, only one method, if not used @Depends
Regarding the “infrastructure” methods: any testing is faced with the fact that it is necessary to configure the environment for testing, download some data, create fake objects, create arrays of the same type for verification. The most important here will be _BEFORE () and _After () (setup () / teardown () in phpUnit) – They will be executed before and after the execution of each test in the classroom, they usually prepare a false environment / objects.

Example of class test:

& lt;? php
Use CodeCeption \ Util \ Stub;
Use \ Core \ http \ httprequest;
Class HttpRequesttest Extends \ CodeCeption \ Testcase \ Test
{
  Protected $ CodeGuy;
  Public Static Function SetupBeforeclass ()
  {
    $ _Server ['Request_Method'] = 'post'; // In the console, most likely, this key will not initially
  }
  Public Static Function TeardownAfterClass ()
  {
    unlink ('dummy.html'); // washed the file created by the test
  }
  Public Function TestispostRequest ()
  { 
$ Request = New httprequest; // Create a tested object. Depending on the nature of the test, the creation may be wiser more in _before ()
     $ this- & gt; AssertTrue ($ Request- & gt; ispostrequest); // Perform directly checking behavior by comparing iSpostrequest with True
  }
}

how to start written?

as always – from the command line. The following command will launch all tests:

CodeCept Run

Because Often you will have to turn to a separate type of testing or in general the test (if the only module fell off, then it’s all to drive all?), then it is better to run tests on this sight or in general a specific test:

CodeCept Run Unit // All unit tests
CodeCept Run Tests / Unit / Core / http / httprequesttest.php // A specific test, a relative path with suffixes and expansion is required.

After that, CodeCeption will display the number of tests, checks (one test may include multiple checks) and errors. It is clear that any number of errors other than zero must be perceived as Build: Failed, and the corresponding code should immediately correct.

Hey, you did not tell anything about the other two types of testing!

Because it really didn’t make it up in them (and I’m too lazy). In principle, Basic Getting Started And any IDE with backlit will be prompted by what – they are very intuitive.

(Previous version of the text about phpUnit)

Modular tests (Unit Tests) in PHP in any framework always rest in the same package: phpUnit. Whatever you encounter, it will have to have to have it with him, perhaps in a small wrapper.
The essence of modular testing is as follows: when developing some application after the appearance (or change) of the planned functionality of this application, in parallel with the application itself, test support is written. Test support is, as a rule, a set of classes that are called an appointment and arrangement, for example:

Appendix:
Models / ProductModel.php
Components / CRMService.php

Tests:
Tests / Models / ProductModeltest.php
Tests / Components / CRMServiceTest.php

(controllers here are not yet specifically mentioned)
Each class is a set of tests for the appropriate component, this set is represented by methods inside the test class for this component. PHPUnit automatically launches all class methods that start with test (and some others, but about it in the documentation), so the typical test class will be approximately such a picture:

class productmodeltest extends testcase {// in this case Testcase is the most wrapper that will be inherited by phpunit_framework_testcase
  Public Function TestGet () // Slash Convention - Call Method by the name of the tested method
  {...} // Checking all sorts of combinations of input and output values ​​for the ProductModel :: get () method
  Public Function TestGetall ()
  {...}
  Public Function TestValidation ()
  {...}
}

Now directly to yii2. Advanced application itself is a simple skeleton (or rather, I found in one common test, but he could not find codeception), so we first need to write some semblance of a model, for example, is . In this psevdomodeli need to test the all methods to a) not to forget the unfinished in the future b) be sure that in any stressful situations, the system will behave exactly as it should be, and c) be alert at precisely that moment, something will fall off due to rewrite the low-level component. Accordingly, each method (blessing them here nothing at all) need to lard all possible incoming values ​​and verify the correctness of working out (or rather, lard it every time something has changed). I have written for this model and a little wacky test (link ), which deals with exactly that. Now you can test the functionality of all this construction, if the model is to throw in a common / models / ProductModel.php , and the test in the common / tests / unit / models / ProductModelTest.php . After that, the common / tests directory will need to perform the following command:

phpunit --bootstrap _bootstrap.php unit / models / ProductModelTest.php

This will launch the appropriate test (default phpunit will attempt to download all files named * Test.php from the current folder and subfolders, in more detail, as always, on the docks) and will give approximately the following conclusion:

PHPUnit 3.6.10 by Sebastian Bergmann.

…….

Time: 0 seconds, Memory: 3.00Mb

OK (7 tests, 18 assertions)

Who says that the 7 tests were successful. When I wrote a model, I checked for id instead of & lt; 1 have & lt; 0, and as a result all invalid aydishniki passed, as I and notified test verification:

PHPUnit 3.6.10 by Sebastian Bergmann.

F ……

Time: 0 seconds, Memory: 3.00Mb

There was 1 failure:

1)
common \ tests \ unit \ models \ ProductModelTest :: testGet
Exception was expected for string input

/srv/sandbox/yii2/apps/advanced/common/tests/unit/models/ProductModelTest.php:14

FAILURES! Tests: 7, Assertions: 6,
Failures:. 1

Such is the chaotic response.
As for the other folders – it’s files to support codeception (in folders with handwriting at the beginning of the name), with whom I did not yet understand (it is testing a higher level, including a phpunit), and files for different types of testing. In fact PHPUnit is suitable only for libraries and applications is a half-measure, albeit quite well protected – in the application should work not only a model, but also controllers, and it is not enough to simulate a situation – you need to pick up nginx / apache (and preferably both) and ensure that the specific requests come true answers. This is called functional testing, to which I myself have not yet reached, and is carried out with the help of a mysterious for me (yet) selenium program. Folder functional, respectively, is responsible for the functional testing. Acceptance, as understood – it is a folder for codeception-test, which goes even further, and instead of simply checking the request / response emulates clicks and display to the user. All together this is called Continuous Integration (CI), and makes it impossible to put in a non-acidic Productions attendance and functionality of some serious gaffe. I am on the weekends all trying to expand myself a full server with all this fun, but really in the projects I still lacked PHPUnit – the rest, of course, useful, but the projects are not to scale)
In any case, to become familiar with the testing would first have to work only with PHPUnit, so the rest can not yet think.