This is the second guestpost from Ragazzo. He writes about using Cest format in functional tests.
As you already saw it is easy to use flat Cept files in Codeception for your tests. But what if you want to test CRUD operations so a Cept can take 50-70 rows long. In this case it would not be so “easy-to-read”.
This is where Codeception’s Cests are really good to use. Cests are simple classes with no parents. You can use them like your classic PHPUnit classes. All that need to know is that each
public Cest method is a separated scenario, which could be represented by a Cept file.
The other issue we want to solve with Cest files is UI mapping. It’s ok to start testing with relying on button names and field labels. But the more UI elements come to page, the more complex our selectors become. There should be a way to manage those UI elements for tests. It’s better not to put too much CSS/XPath code into scenario as it affetcs readbility of code and hardens its support.
Lets see example of testing simple Yii 1.1 application page in Cest-way with
As you see, it was easy to add move out selectors into UI properties if we are inside a calss.
Example of how to test CRUD operations with Selenium2 module is below. Please notice that all support methods are
protected. They are called from test methods and won’t be executed as test themeselves.
In this way you can use Cests classes for some tasks where it is difficult to use flat Cepts. You also can use Cests classes as PageObjects.
When you write tests with Codeception it is good to be verbose and use different methdos for that, so use them:
$I->am to say who you are and define your role;
$I->wantTo to say what feature you want to test;
$I->amGoingTo to say what you gonna do next;
$I->expectTo to say what do expect next to see in your test case as a user.
Use this commands instead of comments in your tests. They will be displayed in scenario output and will provide you with additional information on steps taken.
We can say to Ragazzo for sharing his experience in using the Cest classes. Stil it might be a point of discussion, should a CRUD be tested in one test or in four. In both cases Cest classes are a good places to keep everything you need to test dealing with one entity. A user, in this case.