In this chapter we will cover some techniques and options that you can use to improve your testing experience and keep your project better organized.
If you want to get a class-like structure for your Cepts, you can use the Cest format instead of plain PHP. It is very simple and is fully compatible with Cept scenarios. It means that if you feel that your test is long enough and you want to split it, you can easily move it into classes.
You can create a Cest file by running the command:
The generated file will look like this:
Each public method of Cest (except those starting with
_) will be executed as a test
and will receive an instance of the Actor class as the first parameter and the
$scenario variable as the second one.
_after methods you can use common setups and teardowns for the tests in the class.
As you see, we are passing the Actor object into
tryToTest method. This allows us to write scenarios the way we did before:
As you see, Cest classes have no parents.
This is done intentionally. It allows you to extend your classes with common behaviors and workarounds
that may be used in child classes. But don’t forget to make these methods
protected so they won’t be executed as tests.
Cest format also can contain hooks based on test results:
_failedwill be executed on failed test
_passedwill be executed on passed test
Codeception supports simple dependency injection for Cest and \Codeception\TestCase\Test classes.
It means that you can specify which classes you need as parameters of the special
and Codeception will automatically create the respective objects and invoke this method,
passing all dependencies as arguments. This may be useful when working with Helpers. Here’s an example for Cest:
And for Test classes:
However, Dependency Injection is not limited to this. It allows you to inject any class, which can be constructed with arguments known to Codeception.
In order to make auto-wiring work, you will need to implement the
_inject() method with the list of desired arguments.
It is important to specify the type of arguments, so Codeception can guess which objects are expected to be received.
_inject() will only be invoked once, just after creation of the TestCase object (either Cest or Test).
Dependency Injection will also work in a similar manner for Helper and Actor classes.
Each test of a Cest class can declare its own dependencies and receive them from method arguments:
Moreover, Codeception can resolve dependencies recursively (when
A depends on
B depends on
and handle parameters of primitive types with default values (like
$param = 'default').
Of course, you are not allowed to have cyclic dependencies.
What if you want to execute the same test scenario with different data? In this case you can inject examples
Data is defined via the
@example annotation, using JSON or Doctrine-style notation (limited to a single line). Doctrine-style:
Key-value data in Doctrine-style annotation syntax:
You can also use the
@dataProvider annotation for creating dynamic examples for Cest classes, using a protected method for providing example data:
@dataprovider annotation is also available for unit tests, in this case the data provider method must be public.
For more details about how to use data provider for unit tests, please refer to PHPUnit documentation.
You can control execution flow with
@after annotations. You may move common actions
into protected (non-test) methods and invoke them before or after the test method by putting them into annotations.
It is possible to invoke several methods by using more than one
Methods are invoked in order from top to bottom.
For cases where you need to run tests with different configurations you can define different config environments. The most typical use cases are running acceptance tests in different browsers, or running database tests using different database engines.
Let’s demonstrate the usage of environments for the browsers case.
We need to add some new lines to
Basically you can define different environments inside the
env root, name them (
and then redefine any configuration parameters that were set before.
You can also define environments in separate configuration files placed in the directory specified by the
envs option in
The names of these files are used as environments names
chrome.dist.yml for an environment named
You can generate a new file with this environment configuration by using the
In that file you can specify just the options you wish to override:
The environment configuration files are merged into the main configuration before the suite configuration is merged.
You can easily switch between those configs by running tests with
To run the tests only for Firefox you just need to pass
--env firefox as an option:
To run the tests in all browsers, list all the environments:
The tests will be executed 3 times, each time in a different browser.
It’s also possible to merge multiple environments into a single configuration by separating them with a comma:
The configuration is merged in the order given. This way you can easily create multiple combinations of your environment configurations.
Depending on the environment, you may choose which tests are to be executed. For example, you might need some tests to be executed in Firefox only, and some tests in Chrome only.
The desired environments can be specified with the
@env annotation for tests in Test and Cest formats:
For Cept you should use simple comments:
This way you can easily control which tests will be executed for each environment.
Sometimes you may need to change the test behavior in real time.
For instance, the behavior of the same test may differ in Firefox and in Chrome.
In runtime we can retrieve the current environment name, test name,
or list of enabled modules by calling the
You can access
\Codeception\Scenario in the Cept and Cest formats.
In Cept, the
$scenario variable is available by default,
while in Cest you should retrieve it through dependency injection:
Codeception\Scenario is also available in Actor classes and StepObjects. You can access it with
By default Codeception runs tests in alphabetic order.
To ensure that tests are not depending on each other (unless explicitly declared via
@depends) you can enable
Alternatively, you may run tests in shuffle without changing the config:
Tests will be randomly reordered on each run. When tests executed in shuffle mode a seed value will be printed. Copy this seed value from output to be able to rerun tests in the same order.
Pass the copied seed into
@depends annotation you can specify a test that should be passed before the current one.
If that test fails, the current test will be skipped. You should pass the method name of the test you are relying on.
@depends applies to the
Codeception\Test\Unit formats. Dependencies can be set across different classes.
To specify a dependent test from another file you should provide a test signature.
Normally, the test signature matches the
But to get the exact test signature just run the test with the
--steps option to see it:
Codeception reorders tests so dependent tests will always be executed before the tests that rely on them.
If you have several projects with Codeception tests, you can use a single
codecept file to run all of your tests.
You can pass the
-c option to any Codeception command (except
bootstrap), to execute Codeception in another directory:
To create a project in directory different from the current one, just provide its path as a parameter:
-c option allows you to specify another config file to be used.
Thus, you can have several
codeception.yml files for your test suite (e.g. to to specify different environments
and settings). Just pass the
.yml filename as the
-c parameter to execute tests with specific config settings.
There are several ways to execute a bunch of tests. You can run tests from a specific directory:
You can execute one (or several) specific groups of tests:
The concept of groups was taken from PHPUnit and behave in the same way.
For Test and Cest files you can use the
@group annotation to add a test to a group.
For Cept files, use pseudo-annotations in comments:
.feature-files (Gherkin) use tags:
Groups can be defined in global or suite configuration files. Tests for groups can be specified as an array of file names or directories containing them:
A list of tests for the group can be passed from a Group file. It should be defined in plain text with test names on separate lines:
A group file can be included by its relative filename:
You can create group files manually or generate them from third party applications. For example, you can write a script that updates the slow group by taking the slowest tests from xml report.
You can even specify patterns for loading multiple group files with a single definition:
This will load all found
p* files in
tests/_data as groups. Group names will be as follows p1,p2,…,pN.
In addition to the standard test formats (Cept, Cest, Unit, Gherkin) you can implement your own format classes to customise your test execution. Specify these in your suite configuration:
Then define a class which implements the LoaderInterface
For bash and zsh shells, you can use auto-completion for your Codeception projects by executing the following in your shell (or add it to your .bashrc/.zshrc):
By using the above code in your shell, Codeception will try to autocomplete the following:
-use-vendor-bin is optional. This option will work for most Codeception projects, where Codeception is located in your
But in case you are using a global Codeception installation for example, you wouldn’t use this option.
Note that with the
-use-vendor-bin option, your commands will be completed using the Codeception binary located in your project’s root.
Without the option, it will use whatever Codeception binary you originally used to generate the completion script (‘codecept location’ in the above examples)
Codeception is a framework which may look simple at first glance but it allows you to build powerful tests with a single API, refactor them, and write them faster using the interactive console. Codeception tests can be easily organized in groups or Cest classes.