Why do we write unit-tests? We write them to ensure that developers’ implementation doesn’t change the behaviour of parts of the project. If there is a change in the behaviour, unit-tests throw errors. This keep developers in ease during integration of the software and ensure lower chances of unexpected bugs.
After setting up the tests in Loklak Server, we were able to check whether there is any error or not in the test. Test failures didn’t mention the error and the exact test case at which they failed. It was YoutubeScraperTest that brought some of the best practices in the project. We modified the tests according to it.
The following are some of the best practices in 5 points that we shall follow while writing unit tests:
Assert the assertions
There are many assert methods which we can use like assertNull, assertEquals etc. But we should use one which describes the error well (being more descriptive) so that developer’s effort is reduced while debugging.
Using these assertions related preferences help in getting to the exact errors on test fails, thus helping in easier debugging of the code.
Some examples can be:-
- Using assertThat() over assertTrue
assertThat() give more descriptive errors over assertTrue(). Like:-
When assertTrue() is used:
When assertThat() is used:
NOTE:- In many cases, assertThat() is preferred over other assert method (read this), but in some cases other methods are used to give better descriptive output (like in next examples)
- Using assertEquals() over assertThat()
We can clearly see that second example gives better error description than the first one.(An SO link)
One Test per Behaviour
Each test shall be independent of other with none having mutual dependencies. It shall test only a specific behaviour of the module that is tested.
Have a look of this snippet. This test checks the method that creates the twitter url by comparing the output url method with the expected output url.
This unit-test tests whether the method-under-test is able to create twitter link according to query or not.
Selecting test cases for the test
We shall remember that testing is a very costly task in terms of processing. It takes time to execute. That is why, we need to keep the test cases precise and limited. In loklak server, most of the tests are based on connection to the respective websites and this step is very costly. That is why, in implementation, we must use least number of test cases so that all possible corner cases are covered.
Descriptive test names that are short but give hint about their task which are very helpful. A comment describing what it does is a plus point. The following example is from YoutubeScraperTest. I added this point to my ‘best practices queue’ after reviewing the code (when this module was in review process).
AND the last one, accessing methods
In general, such changes to access specifiers are not allowed, that is why we shall resolve this issue with the help of:-
- Setters and Getters (if available, use it or else create them)
- Else use Reflection
If the getter methods are not available, using Reflection API will be the last resort to access the private and protected members of the class. Hereunder is a simple example of how a private method can be accessed using Reflection:
I should end here. Try applying these practices, go through the links and get sync with these ‘Best Practices’ 🙂
- Loklak Server Tests directory: https://github.com/loklak/loklak_server/tree/development/test
- Reflection API: https://docs.oracle.com/javase/tutorial/reflect/
- Testing with hamcrest: http://www.vogella.com/tutorials/Hamcrest/article.html
- Assertions: http://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html