Let's take a look at Codeception's architecture. We'll assume that you have already installed it and bootstrapped your first test suites. Codeception has generated three of them: unit, functional, and acceptance. They are well described in the previous chapter. Inside your /tests folder you will have three .yml config files and three directories with names corresponding to these suites: unit, functional, acceptance. Suites are independent groups of tests with a common purpose.

Codeception follows simple naming rules to make it easy to remember (as well as easy to understand) its method names.

• Actions start with a plain english verb, like "click" or "fill". Examples: {% highlight php %}

  click('Login'); $I->fillField('#input-username', 'John Dough'); $I->pressKey('#input-remarks', 'foo');

{% endhighlight %}

• Assertions always start with "see" or "dontSee". Examples: {% highlight php %}

  see('Welcome'); $I->seeInTitle('My Company'); $I->seeElement('nav'); $I->dontSeeElement('#error-message'); $I->dontSeeInPageSource('
  ');

{% endhighlight %}

• Grabbers take information. The return value of those are meant to be saved as variables and used later. Example: {% highlight php %}

  grabAttributeFrom('#login-form', 'method'); $I->assertEquals('post', $method);

{% endhighlight %}

One of the main concepts of Codeception is representation of tests as actions of a person.We have a UnitTester, who executes functions and tests the code. We also have a FunctionalTester, a qualified tester, who tests the application as a whole, with knowledge of its internals. Lastly we have an AcceptanceTester, a user who works with our application through an interface that we provide.

Methods of actor classes are generally taken from Codeception Modules. Each module provides predefined actions for different testing purposes, and they can be combined to fit the testing environment. Codeception tries to solve 90% of possible testing issues in its modules, so you don't have to reinvent the wheel. We think that you can spend more time on writing tests and less on writing support code to make those tests run. By default, AcceptanceTester relies on PhpBrowser module, which is set in the tests/acceptance.suite.yml configuration file:

{% highlight yaml %}

actor: AcceptanceTester modules: enabled: - PhpBrowser: url: http://localhost/myapp/ - \Helper\Acceptance

{% endhighlight %}

In this configuration file you can enable/disable and reconfigure modules for your needs. When you change the configuration, the actor classes are rebuilt automatically. If the actor classes are not created or updated as you expect, try to generate them manually with the build command:

{% highlight bash %}

php vendor/bin/codecept build

{% endhighlight %}

Codeception has its own testing format called Cest (Codecept + Test). To start writing a test we need to create a new Cest file. We can do that by running the following command:

{% highlight bash %}

php vendor/bin/codecept generate:cest acceptance Signin

{% endhighlight %}

This will generate SigninCest.php file inside tests/acceptance directory. Let's open it:

{% highlight php %}