There are no "rules" other than the "rules" you set for yourself.
Discuss the game with the other players!
Simple (and specific) rules
- Make sure to declare a PHP constraint in the
composer.jsonDifferent versions of PHP are supported by different versions of PHPUnit. Setting the PHP version makes sure a compatible PHPUnit version is required.
- Add any extensions to the
requiresection To avoid tests failing because a certain extension is not installed, explicitly mention the needed extensions in the
composer.jsonfile. That way when
composer install(or update) is run to fetch PHPUnit (and other dependencies), composer will report the missing extension.
- Add PHPUnit as a development dependency (using
composer require --dev 'phpunit/phpunit')
To make sure the a version of PHPUnit is used that can actually run a projects tests (either because the API the tests use or the PHP version that PHPUnit requires), ship a PHPUnit with a project by declaring it as development dependency.
- Use the PHPUnit shipped with a project, not a globally installed one.
- Do not mix API's from different PHPUnit versions
Write tests for a specific version of PHPUnit.
- Do not commit the
- Declare the PHPUnit version in the
By declaring the correct
xsi:noNamespaceSchemaLocation, a specific version of PHPUnit XML configuration can be specified. This makes it possible for XML enabled editors to autocomplete configuration settings. This saves time looking things up in the manual.
- Use one assert per test method
- Undecided Use the static
Asserts provided by PHPUnit are all static. The abstract
TestCaseclass extends the abstract
Assertclass. One could even go as far as using
More advanced (and more generic) rules
- Add separate methods to create Mocks
When a mock is needed more than once, for the sake of readability (and to reduce code duplication) create a method that creates the mock. In extension of PHPUnit's
getMockfunction, naming a method that creates a mock
Fooshould be named
- Test structure should mirror code structure
A class that tests
Fooshould be called
FooTestand should live in the same namespace.
- Test classes should be named after the class they are testing
- Test method names should be TestDox/AgileDox compatible
- Test method names should contain the subject of the test
- Test method names should contain the expected behaviour of the test
- Test method names should contain the context of the test
Method name format: