posted on 2013-10-24 11:34:10
Under the title Top 12 Selected Unit Testing Best Practices I found a list of notes on unit testing. Copy pasted them here and added some own notes.
1) Always Write Isolated Test Cases
- The order of execution has to be independent between test cases
JUnit can run tests in parallel IIRC, so this is a no-brainer. ALWAYS stick to this principle, else results will not be reproduceable. Non-reproduceability SI TEH EVIL, be it in building or testing.
2) Test One Thing Only in One Test Case
- Each test should focus on one aspect of an isolated method and/or class
This makes debugging easier and renders tests easier readable.
3) Use a Single Assert Method per Test Case
- Don't test too many different things at once! If you use just one Assert it's easier
This is the like 2), but goes further. Also growth of the test suite is directly visible in the amount of tests run. Senses of achievement are good for the programmers mind.
4) Use a Naming Convention for Test Cases
- A convention like:
<Method-Name Under Test>_<Scenario>_<Expected-Outcome>
Readability and easier debugging through having information at a glance in the log... looks like a lot of doubled work, especially if tests are subject to change. But bear with it, it simply helps.
5) Use the AAA Pattern
- Use separated blocks ("ARRANGE", "ACT" and "ASSERT") help to improve maintainability
- Use comments to mark the blocks
I am not completely sure what this means. Maybe this relates to other unit testing frameworks than JUnit, where there are no explicit
@After Task grouping mechanisms. If you have such a kind of approach, it could be helpful to document it in the header of your test file, even if you think your ideas are self-explanatory. If in doubt, document it, except it is likely to become obsolete again too soon.
6) Avoid the Expected Exception Tests
@Test(expected = ArithmeticException.class) doesn't test what it claims to test
Expected failtests are implicit. Be explicit whenever possible.
7) Structure All Test Cases
- Like Short-/Long-Running, Integration-/Unit-tests, but don't use test suits to control order of execution
Order of execution or other depencenies are bad, same as 1).
8) Use Descriptive Messages in Assert Methods
- Describe the WHY and not the WHAT, not like Assert.assertEquals( a, b, "must be equal")
This is always key in documentation, be it in code documentation, changelogs or whereever. No matter in what language or what kind of code you are working on. Proofread stuff with this in mind.
9) Measure Code Coverage to Find Missing Test Cases
- Best indicator what is not tested, but don't be too sure that the code works
This helps for coming across parts of untested code, but may lead to false positives. 'Covered' code has tests written about it to check parts of itself, but this says nothing on the correctness of the tests by itself. Or, just as worse, not all test cases are covered by the test suite. Still it looks great for your boss, the higher the coverage key figure rises. :-)
10) Don't Forget to Refactor the Test Code
- Also maintain your test code
Basically there are like two types of refactoring. In short, one is reordering code within single method, which has little consequences. Ideal case for using tests. The other refactoring type is when you rebuild larger parts of software architecture, rendering your corresponding tests useless.
The more you think about proper design up front, the less refactoring of the second type is needed. Once huge parts of application code have to be refactored due to bad design, most of the time the amount of work, like, doubles when code is already fully tested... You get the idea. Some of the information sitting in the tests (domain knowledge) can be reused, but all tests need reworking. Here keep in mind, that 'perfect' is the enemy of 'good enough', and nobody gets paid for gold plating. If you are paid for gold-plating, that is a sign of deeper-rooting problems at work...
11) Limit Use of Mocks
- In some cases absolutely necessary, but with better design stubs should be enough
I have never thought about this. But I just realized I have to refresh my knowledge on Mocks vs. Stubs.
12) Use Parameterized Tests
- They can help avoid duplication and the best is the business gives you the data
For a lot of code to be tested, there are like three tests needed. This means one for the left border, one for the right border and one test for the data span in between. Of course, if there are more gaps in the domain of the data, more tests are needed. Anyways, parameterized tests are great if just your input data changes because they mean less work for you.
Sidenote: The better the specification, the easier it is writing correct tests. Basically better reqirements engineering up front makes test work easier afterwards.
View posts from 2017-05, 2017-04, 2017-03, 2017-02, 2017-01, 2016-12, 2016-11, 2016-10, 2016-09, 2016-08, 2016-07, 2016-06, 2016-05, 2016-04, 2016-03, 2016-02, 2016-01, 2015-12, 2015-11, 2015-10, 2015-09, 2015-08, 2015-07, 2015-06, 2015-05, 2015-04, 2015-03, 2015-02, 2015-01, 2014-12, 2014-11, 2014-10, 2014-09, 2014-08, 2014-07, 2014-06, 2014-05, 2014-04, 2014-03, 2014-01, 2013-12, 2013-11, 2013-10