...
Our unit tests are written using the testing framework JUnit version 4. (Currently Migrating to JUnit version 5)
When writing unit tests you should make sure that they
...
- If committing new code, the unit tests for that code should be committed at the same time
- when you create a pull request on Github you should make sure that your tests passed (Travis CI will report back if they did not) and you should also make sure you did not decrease code coverage (coveralls.io will report back on this)
- Do not write tests for private methods as these are internals/implementation details that can quickly change. Test public methods only. Think of them as the contract that we agree on and promise to keep. The tests should consider the methods they test as a black box:
- example
public int add(int a, int b): you pass in two values and expect the method to return you the sum, assert (check) that the return value is as you expected
- example
- Every unit test must use an assertion (Assert.assert___ methods to test output...not println statements!) that checks whether the expectations you have in this test are met. A test without assertions passes, which could hide that a method does not return what you expected. So add assertions.
- Look at the coverage and ensure that you tested all possible cases (branches in an if/else or switch/case), parameter's and states (what if you call the method with
null, an emptyList, ...) - If fixing a bug, write a failing test proving the bug, then fix the code to make the test pass.
- Every database-based test must be accompanied by a in-memory dbunit test dataset, described here.
...