Improving our server side testing methods

Unit Testing

• 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

The Problem – Summary of issues with server unit tests

• 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

What is a Unit

• Describes specification

• Code maintainability

• Improves the design of the code

• Documents the code

• Reduces bugs

• Identifies regressive behaviour

• Helps peer review process of code

Why Unit Test?

• 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

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

DAMP vs DRY – Paradigm Shift

• 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

What Unit Tests Should Look Like?

• 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

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

What Unit Tests Should Look Like? (cont…)

“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