
Codeception 1.1 released
The framework for automatic testing of PHP projects Codeception got the first major update. I had to shovel the whole core, break everything, fix everything and do it so as not to break backward compatibility. As a result, now you can use any PHP code in the tests, not just a script, the ability to find elements using XPath has been added, and you can now use Codeception modules in PHPUnit tests.
In the comments of one of the previous articles, the Khabrovsk resident sqrt asked: “is it possible to return the result when calling the helper method so that it can be used in a test script?”
Previously, this did not work out, but in the new version it is possible. Added special teams - grabbers . They all begin with the prefix “grab” and are now included in almost all modules.
So now you have to write your helpers less often, and most tasks can be done right away in the test. In addition, now any PHP code can be written in the test. It would seem, why this is necessary - let the test have a clear structure, and there is no need to let the developer write anything. In the absence of strict rules, the test is likely to lose readability. But strict rules remain, but the ability to embed PHP simplifies working with fixtures.
For instance:
User $ user1 was loaded from user_data.php and removed at the end of the test.
Earlier in Codeception, the following strategy was practiced: all data is equally loaded and cleared for all tests in the group. Now developers are given greater flexibility in working with data.
It is necessary to clarify that when inserting any code it is necessary to indicate when it should be executed: on the analysis of the script or already during its execution. Actually, for this, the if ($ scenario-> preload ()) and if ($ scenario-> running ()) blocks are needed.
As an indirect consequence of the refacotring, now in PHPUnit tests you can use Codeception modules . Those. In principle, you can throw away scripts and write all acceptance tests in PHPUnit. Everything will look something like this:
But personally, I would recommend using these features to write integration tests. Modules for working with a database or ORM Doctrine will be very useful there.
And finally, one more innovation. Now tests can find elements by XPath locators. At the same time, no new commands were introduced into existing modules. Where CSS selectors were previously used, XPath locators can now be used.
That's all. Thanks for attention. Test it!
Release details on the official blog .
In the comments of one of the previous articles, the Khabrovsk resident sqrt asked: “is it possible to return the result when calling the helper method so that it can be used in a test script?”
$token = $I->grabTextValueFrom('#token');
$I->fillField('token', $token);
Previously, this did not work out, but in the new version it is possible. Added special teams - grabbers . They all begin with the prefix “grab” and are now included in almost all modules.
So now you have to write your helpers less often, and most tasks can be done right away in the test. In addition, now any PHP code can be written in the test. It would seem, why this is necessary - let the test have a clear structure, and there is no need to let the developer write anything. In the absence of strict rules, the test is likely to lose readability. But strict rules remain, but the ability to embed PHP simplifies working with fixtures.
For instance:
preload()) {
require 'user_data.php'
}
$I = new TestGuy($scenario);
$I->amLoggedAs($user1);
$I->click('Log In');
$I->see("Hello, ".$user1->name);
if ($scenario->running()) {
$user1->delete();
}
?>
User $ user1 was loaded from user_data.php and removed at the end of the test.
Earlier in Codeception, the following strategy was practiced: all data is equally loaded and cleared for all tests in the group. Now developers are given greater flexibility in working with data.
It is necessary to clarify that when inserting any code it is necessary to indicate when it should be executed: on the analysis of the script or already during its execution. Actually, for this, the if ($ scenario-> preload ()) and if ($ scenario-> running ()) blocks are needed.
As an indirect consequence of the refacotring, now in PHPUnit tests you can use Codeception modules . Those. In principle, you can throw away scripts and write all acceptance tests in PHPUnit. Everything will look something like this:
public function testUserIsLoggedIn()
{
$user = User::find(1);
$user->setPassword('qwerty');
$user->save();
$this->testGuy->amOnPage('/login');
$this->testGuy->submitForm('#login', array('username' => $user->name, 'password' => 'qwerty'));
$this->testGuy->see('Hello, '.$user->name);
}
But personally, I would recommend using these features to write integration tests. Modules for working with a database or ORM Doctrine will be very useful there.
And finally, one more innovation. Now tests can find elements by XPath locators. At the same time, no new commands were introduced into existing modules. Where CSS selectors were previously used, XPath locators can now be used.
That's all. Thanks for attention. Test it!
Release details on the official blog .