[Removing duplication in tests] (Part 1) Move wiring of objects to class attributes

Recommended reading before you read this article: Mockito basics

Hot to get rid of duplicated code in tests

When we have multiple tests and all of them have similar givens we are tempted to extract those common givens to setup method or the field declarations. This might be a good idea when those givens are just wiring of dependencies. In most other cases it might be not a good idea.
Below I include an example for correct removing duplication of “givens” for multiple tests. Moving wiring of objects in field declarations. This way we do not test the wiring in the test, just the business functionality. The wiring should be tested in acceptance or end to end tests, not on unit level.

The example below also replaces string constants with variable names. For example in the tests we don’t care that the username is “john”. We only care that the username passed around is the same object. So we can move the definition of username out of the test to increase readability.

Please note that all fields are marked as final. This ensures that all wiring was done before we start testing the user object.

Before refactor

After refactor

I have not found any other scenarios for removing duplication in tests by moving common code into set up methods or class attributes. All other scenarios where duplication occurs pointed to problems in production code and design issues. Please take a look at all other parts for further details (coming soon).

Please comment! 🙂

Testing time dependant functionalities

Recommended reading before you read this article: Mockito basics, Fest assertions.

How do we test time dependent operations?

Let us assume we have a report and it may me marked as complete. When it is marked as complete the “completed on” date should be set. The easiest approach would be to do a “new Date()” and assign it to “completed on” attribute.

But how do we test it? We have to take an other approach.
The solution is to introduce a Clock object that can be asked for the current time and which we will be able to mock in tests:

Recommended further reading: How NOT to test drive time dependant functionalities

The ultimate test template

Recommended reading before you read this article: Mockito basics, Fest assertions.

When doing OOP we create objects. While doing TDD we should focus on relationships between those objects. That being said, one of the main principles that we should focus on is “Tell Don’t Ask”. We tell object “do this thing” and expect a certain result. This leads us to the “ultimate test template”, a test should have 3 parts: inputs for the tested object, call on the object and then asserting for the expected results, for example:

This is a very basic example just to illustrate the 3 parts of the test. The input is that the User object was supplied with an observer. The output is that if user changed password is that the observer was notified. (This example uses Mockito mocks to create a mock object and then verify if a method was called on it).

You might notice the comments //given //when // then. At the beginning I added them each time I was staring a new test, but after a while I realised that this just adds noise. When you know that each test will have those 3 parts I would skip the comments.

Sometimes the first or third parts may be skipped of course. For example we may skip the first part (the givens are in the same line as the call for readibility):

Or we can skip the first and last part. The third part is moved to the annotation parameters:

InteliJ IDEA users

You might add a live template to your IDE. Go to File->Settings->Live Templates.
Add the listing below to “plain” category. The abbreviation should be “test”.
Do not forget to check “Context -> Java Code”.

Now when you type “test” and pres TAB in a java file the test template will appear.