Let's look at this test.

{% highlight php %}

$I->seeFileFound('running.lock');

?>

{% endhighlight %}

It can operate with different entities: the web page can be loaded with Symfony1 module, the database assertion uses Db module, and file state can be checked with Filesystem module.

Modules are attached to Guy-classes in suite config.

For current example in 'tests/functional.suite.yml' we should see.

class_name: TestGuy

modules:

enabled: [Symfony1, Db, Filesystem]

The TestGuy class has it's methods defined in modules. Actually, it doesn't contain any of them, but acts as a proxy for them. It knows which module executes this action and passes parameters into it. To make your IDE see all methods of TestGuy listed, you use the 'build' command. It generates definition of TestGuy class by copying signatures from modules.

Let's say we are going to extend TestHelper class. By default it's linked with a TestGuy class and functional test suite.

{% highlight php %}

{% endhighlight %}

As for actions everything is quite simple. Every action you define is a public function. Write down any public method, run 'build' command, and you will see this function added into TestGuy class. Still, public methods prefixed by '_' are treated as hidden and won't be added you your Guy class.

Assertions are a bit tricky. First of all it's recommended to prefix all your assert actions with 'see', or 'dontSee'. In Codeception philosophy all tests are performed by humans, i.e. guys. The expected result they see (or they don't) is what we use for assertion.

Name your assertions like:

seePageReloaded();

seeClassIsLoaded($classname);

dontSeeUserExist($user);

And then use them in your tests:

{% highlight php %}

$I->dontSeeUserExist($user);

?>

{% endhighlight %}

Every 'see' or 'dontSee' function requires at least one assert. Codeception uses PHPUnit assertions.

You can define asserts by using assertXXX functions, from 'PHPUnit/Framework/Assert/Functions.php' file.

In case your application falls into conflict with one of this functions, you can use PHPUnit static methods from class PHPUnit_Framework_Assert to define asserts.

{% highlight php %}

{% endhighlight %}

Each module has special $this->assert and $this->assertNot methods. They take the same arguments and are useful if you need to define both positive and negative assertions in your module. This functions take an array as parameter, where the first value of array is the name of PHPUnit assert function.

{% highlight php %}

$this->assert(array('Contains', array(3,5,9), 3));

?>

{% endhighlight %}

Let's see how define both 'see' and don't see action without code duplication.

{% highlight php %}

}

?>

{% endhighlight %}

For dontSeeClassExist, the 'assertFalse' will be called.

Let's imagine we are writing module which reconnects to database. It's supposed to use the dbh connection value from Db module.

{% highlight php %}

}

?>

{% endhighlight %}

By using getModule function you get access to all public methods and properties of module.

The dbh property was defined public specially to be avaible to other modules.

That may be also useful if you need to perform sequence of actions taken from other modules.

For example:

{% highlight php %}

}

?>

{% endhighlight %}

Here are they listed. You are free to redefine them in you module.

{% highlight php %}

{% endhighlight %}

Please, note, that methods with '_' prefix are not added to the Guy class. This allows them to be defined as public, but used for internal purposes.

To print additional information use debug amd debugSection methods of module.

Here is the sample how it works for PhpBrowser:

{% highlight php %}

$this->debug('Request ('.$method.'): '.$uri.' '. json_encode($params));

$browser->request($method, $uri, $params);

$this->debug('Response code: '.$this->session->getStatusCode());

?>

{% endhighlight %}

The test running with PhpBrowser module in debug mode will print something like this:

I click "All pages"

* Request (GET) http://localhost/pages {}

* Response code: 200

Modules can be configured from suite config file, or globally from codeception.yml.

Mandatory parameters should be defined in $$requiredFields property of module class. Here how it is done in Db module

{% highlight php %}

{% endhighlight %}

Next time you start suite without this values set, an exception will be thrown.

For the optional parameters you should have default values set. The $config property is used to define optional parameters as well as their values. In Seleinum module we use default Selenium Server address and port.

{% highlight php %}

protected $config = array('host' => '127.0.0.1', 'port' => '4444');

?>

{% endhighlight %}

The host and port parameter can be redefined in suite config. Values are set in 'modules:config' section of configuration file.

modules:

enabled:

- Selenium

Db:

cleanup: false

repopulate: false

Optional and mandatory parameters can be accessed through the $config property. Use $this->config['parameter'] to get it's value.

Writing Codeception tests is just the same as describing actions you perform on a site. Only the basic knowlegde of HTML and PHP is required for wrinig such tests.

``

{% highlight php %}

$I->see('Welcome, Davert!');

?>

{% endhighlight %}

With no knowledge in PHP or HTML you can still read this scenario. Or not?

Well, if you have problems reading this, Codeception can convert this scenario into text written mostly in native English:

``

I WANT TO SIGN IN

I am on page '/login'

I fill field ['signin[username]', 'davert']

``

This scenario can be performed in either simple PHP browser or within the browser through Selenium (also Sahi or ZombieJS).