Creating good unit tests

1. Unit Testing
Improving our server side testing
methods

2. The Problem – Summary of issues with
server unit tests
• Unit not well defined
• Dependency on other classes
• Small change breaks tests across several projects
• Purpose not always obvious
• Many tests only assert that the result is not null
• Asserting guards – not expectations
• Tests are not always easy to read
• Poor naming conventions
• Not always well structured
• Dependencies on test superclasses
• Not alone in these issues – companies fail in getting testing right

3. What is a Unit
• A “Unit” is a java class
• Most classes which perform operations should be unit tested
• Exceptions:-
• Model objects
• DAO – persistence managers
• Cover all methods and paths
• Dependencies should be mocked
• Mockito
• PowerMockito

4. Why Unit Test?
• Describes specification
• Code maintainability
• Improves the design of the code
• Documents the code
• Reduces bugs
• Identifies regressive behaviour
• Helps peer review process of code

5. DAMP vs DRY – Paradigm Shift
• DAMP (Descriptive And Meaningful Phrases)
• Useful for unit testing
• Promotes the readability of the code
• Prioritises readability over duplication of code
• Duplication is usually localised
• DRY (Don't repeat yourself)
• Useful for production code
• Remove duplication
• Every concept has a single authoritative representation in code
• Reduces risk of change if only in one place

6. DAMP vs DRY – Paradigm Shift
“So, why is duplication more acceptable in tests?
Tests often contain inherent duplication because they are testing the same thing
over and over again, only with slightly different input values or setup code.
However, unlike production code, this duplication is usually isolated only to the
scenarios within a single test fixture/file. Because of this, the duplication is minimal
and obvious, which means it poses less risk to the project than other types of
duplication.
Furthermore, removing this kind of duplication reduces the readability of the tests.
The details that were previously duplicated in each test are now hidden away in
some new method or class. To get the full picture of the test, you now have to
mentally put all these pieces back together.
Therefore, since test code duplication often carries less risk, and promotes
readability, its easy to see how it is considered acceptable.
As a principle, favour DRY in production code, favour DAMP in test code. While
both are equally important, with a little wisdom you can tip the balance in your
favour.”
- Chris Edwards - Stackoverflow

7. What Unit Tests Should Look Like?
• Each test should look as simple as possible
• The name should be meaningful
• If the name contains either “And” or “Or” –
split the test into two tests
• Split up tests which use if/else
• Test only one thing per test
• Variable names: camel case plain English – not
abbreviations.
• Avoid using literal values

8. What Unit Tests Should Look Like? (cont…)
• Assert what we are expecting – not null pointers
• Use builders to construct test data
• Testing exceptions should be done with
annotations
e.g. @Test(expected =
AirpointInternalException.class)and not
using try/catch fail()
• Don’t make over use of setup methods

9. What Unit Tests Should Look Like? (cont…)
• Use a template to separate test setup, execution
and exceptions. E.g.:
// given
Setup
// when
Do something
// then
assert

10. “Now this is not the end. It is not
even the beginning of the end. But it
is, perhaps, the end of the
beginning.”
- Winston Churchill
Comments and Questions