#TDD guidelines: To have a better TDD experience we set up some guidelines. For unit testing we use xUnit terminology. The xUnit book is written by Gerard Meszaros. Online information about xUnit can be on the xUnit website.

##Code Coverage:

• The code coverage of the application must be at least 90%
• The build process must fail if the coverage is lower then 90%
• The coverage report must be available on the build server and should be available locally.
• The coverage must be calculated over the complete library not only the files that are covered by unit tests.
• Files that can be excluded from coverage:
  • Bootstrappers
  • Definition or configuration files.
  • Main method or starting point of the application.
  • Queries
  • Third party code
  • Templates

##General testing guidelines

• First think of the scenario's and create the tests after that create the implementation.
• Tests that are unfinished or not not implemented must fail.
• Tests should be reliable and fast.
• A test must have at least one meaningful assertion. No AssertTrue(true) for example.
• A test must be build using the AAA pattern.
• A bug that is fixed should be covered by a test. Unless the bug is in a file that is excluded for testing.
• Only test one scenario in a test. It's allowed testing the same scenario with different parameters.
• Tests should not have any dependencies to other tests.
• All tests must be able to run on his own in any order.
• Only create tests for scenarios's that are in scoop of the code.
• Don't repeat yourself with every scenario. Test the behavior only in the happy path and only if needed in other scenarios.
• Make use of test suites to group the test by functionality.
• The tests must use the same folder structure as the library.
• For every file or class create a test file. Different types of testing (Unit test, Integration test and Acceptance test) must have there own file.
• If fake test doubles are created and stored with the test. At "Fake" suffix to the filename. for example clientFake.php.

###Unit tests

• Always use test doubles in the tests.
• Always try to test the behavior, state or output.
• Use "Test" suffix in the name of the file. For example if the file client.php is tested call the test file clientTest.php.

###Integration tests

• Only use test doubles where needed for example to mock the database connection. Use spies to test the behavior.
• Use "IntegrationTest" suffix in the name of the file. For example if the file client.php is tested call the test file clientIntegrationTest.php.

###Test doubles Use the correct test double for the job.

• Use a fake for a static implementation that doesn't need to be tested.
• Use a spy for behavior verification, but use a real implementation.
• Use a mock for behavior verification, but use a fake implementation and set expectations.
• Use a stub for a fake implementation to manipulate the results.

If the test double is assigned to a variable in the test, use the test double type in the variable name for example: clientFake, clientMock, clientStub or clientSpy.