Best rules to write JUnit test cases

Question

We have a project with > 80% test coverage but the quality of the code is still a problem. Some changes will bring in new bugs ever with test cases to cover the logic. What's the best rules to write the JUnit test cases?

Answer 1

• A tip first: when developing new code, start doing it in a unit test
• Do not start with border cases, null tests
• Make stable tests, which will not easily be broken with source changes
• For scenarios with business data, sequences, make help functions
• Catching regression errors, weakness in the code usage is the main goal
• New code often merits to be redesigned, a rewrite when some additional functionality crystallizes. A unit test should not be a burdon, and be entirely rewritten too

Some effort can better go into the tested code. 100% coverage also implies that much effort went into test code and its maintenance.

However if a unit test of a source is cumbersome, refactor the original code by splitting responsibilities. This can be done ugly by using inheritance for separating different aspects.

Rely on findbugs/coverity, selenium and such too.

Answer 2

You said "Some changes will bring in new bugs ever with test cases to cover the logic". My question is what kind of bugs are introduced? Are these functional bugs say missing a functionality or a functionality not working as expected even though the code and Unit test both are there. Then I would say you need to do some requirement mapping. Junits are not only helpful to cover the "written code", but you should also look at the requirements/scenarios and there should be atleast one unit-test for each scenario. Every time there is a change in functionality, make sure you update/add the Junit first (so it will start failing), then update/add/remove code. So the failed Junit now start passing.