Testing Conventions

Genral Information

Code Coverage

As of writing this document our project stands at ~60% code coverage. We aim to raise the coverage to 70% on all System related classes (not including the System GUI - which will be tested as much as possible using TestFx) i.e. we will exclude all classes that are application or sensor related from the calculation. We use the CodeCov platform to check our code coverage.

Running The Test

Run mvn test from the root of the repository.

Continues integration

Using Travis. Each commit invokes all of the tests to run, simulating a regression check. if a programmer screwed up the system with his change we get notified.

Testing GuideLine

There are a lot of ways on how a developer can do JUnit test cases, but overall it really depends on the strategy of how a specific functional code can be tested to it’s limits. It’s the developers responsibility to introduce thorough test cases to make sure that the code is stable and ultimately does what it has to do. here are some general rules of thumb:

Avoid writing test cases that can cause impact

Test cases that can cause impact exhibit the following problems:

• Test cases that manipulates data
• Test cases that require manual intervention

Sensible Test Case names!

All developers would agree on this. The test cases names should be valid and meaningful.

Also, test classes' names must use the following naming conventions:

• Test*
• *Test
• *TestCase

By default Maven uses the following naming conventions when looking for tests to run.

Always aim to do one assertion for each test method

One assertion = One test method. That’s the rule of thumb. If that rule is not followed try to break down the redundant scenarios.

Assertions, maximize it!

The JUnit Assert package has a lot of methods that can be used to do test cases. Combine this with a hamcrest and you get an extremely powerful api that uses pattern matching utilities.

Annotations, use them!

The following are the basic and mostly used annotations. @RunWith – Use to specify a runner object that the test case will be called from. @Test – use to tag a method as a test case. @Before – use to tag a method to be called before a test case. This usually being used to initialse data for the test case. @After – use to tag a method to be called after a test case. This is usually used to do clean up processes. There’s more useful annotations available and developers should maximise these.

Don’t just pass the test just for the sake of passing it!

Of course, everyone can just write ‘assert(true)’ just for the sake of passing a test case, but then what’s the point of doing it in the first place? The whole strategy of doing Junit test case is the fact that we want to ensure that the system is stable and scalable against any new extensions and requirements.

Be creative with your test case!

There will be a lot of scenarios possible for your test cases. It’s not just about testing your Java Service code and checking if it will give you any exception. It should do what it supposed to do.

more information can be found in this terrific Blog Post who wrote this rules of thumb and elaborates some more on the best practices of Junit testing