Testing Guidelines

Overview

We ask developers to run existing tests and to provide tests for their contribution for two main reasons:

• The code they add should not break existing code
• Future modifications should not break their contribution

In this context, we ask contributors to follow these guidelines:

1. make sure that existing tests still pass after having added their contribution
2. update existing tests if they need to be adapted
3. add tests for their contribution (expected coverage for new code is 80%)
4. test method names must follow expected naming scheme (see below)
5. if a test needs to assert multiple conditions that need to be considered as a whole, use assertj's SoftAssertions
6. if there is the need to add a third party test library, please first discuss with us in order to make sure that we agree on the library and on the version to be used.
7. if there is the need to change a test library version, please first discuss with us in order to make sure that we won't introduce compatibility issues

What we do not ask developers to do (but help is really appreciated):

• add missing tests for preexisting code

Naming test methods

We want to have our unit test methods self explanatory and as clear as possible. Therefor contributors must respect the following convention:

// when testing a SUT's constructor
<class name>_(when|with|using)_<whatever you want>_should(Not)?(Throw)?_<whatever you want>
// when testing a SUT's method
<tested method name>_(when|with|using)_<whatever you want>_should(Not)?(Return|Throw)?_<whatever you want>
// when testing a SUT's constant
constant_<tested constant name>_should(Not)?_<whatever you want>

While using _ instead of lowerCamelCase may seem ugly at first sight, using this convention for test methods brings two advantages:

• test methods are nicely ordered in your IDE's class overview
• when a test fails it is extremely easy to know what method has been impacted