6 Tips for Writing Useful Unit Tests

Unit testing is a software development process in which the smallest testable parts of an application are individually tested for proper operation. This is a fundamental step in the development cycle in which developers make sure their code is behaving as expected.

Check out the following six tips to bring yourself up to speed and write more valuable unit tests.

Use Descriptive Names

When writing unit tests, try to be as descriptive and explicit as you can. The test name should provide enough information to developers so they can quickly grasp what exactly it is doing/testing, under what circumstances it’s being done, and what the expected output is. A common name convention I would personally recommend using is the following pattern:

test[MethodName]_with[StateUnderTest]_expectedBehavior

validateEmployee_withValidInput_returnsTrue();

validateEmployee_invalidDateOfBirth_returnsFalse();

calculateSum_withNullValues_shouldSkipAndReturnTheSum();

Keep Tests Short and Simple

Unit tests shouldn’t test the whole application, but rather a small chunk of code. In a typical Spring Boot application, unit tests should cover each controller, each service, each repository, and each utility/helpers/mapping class in complete isolation. Unit tests should not load/import any spring context, load any environment configuration, connect to any database, or call any third-party service.

Make Use of Assertions on Your Tests

On many occasions, I’ve seen unit tests that are not validating the responses/output of a given method. Even though the code coverage may be there, the tests are not actually checking the appropriate behavior. So, please make sure to add the proper assertions to your tests.

Code Coverage

The code coverage metric is an easy way to identify which parts of the code have been tested through automation and which ones have not. The dilemma of the recommended target percentage to be covered will always exist among developers. Speaking from my personal experience, I would recommend the sweet spot of 80% code coverage. However, please consider the following:

Exclude DTOs (data transfer objects) and database models from the code coverage. These classes are usually simple POJOs (plain old Java objects), and there is no need to be testing these getters and setters in the unit tests.
Run code coverage for your own benefit, not just to meet a coverage requirement. You might discover that you are missing tests for critical parts of your code.
Exclude end-to-end tests from your code coverage. A single end-to-end happy path might cover roughly around 70% of your code, which could give a false sense of proper test coverage.

Learn and Make the Most of Mockito

Mockito is one of the most powerful frameworks for writing clean and readable tests. It provides the tools to test your code in complete isolation by mocking any interfaces within the same app or any third-party application. I suggest learning at least the following annotations: @Mock, @InjectMocks, and @Spy. For more advanced tests, you can go through @Captor and ArgumentCaptor class. Check out Baeldung’s Mockito Tutorial for both basic and in-depth information about Mockito.

Confirm Acceptance Criterias (ACs) with End-to-End (E2E) Tests

As user stories and acceptance criterias are usually focused on what the business really cares about, they are most likely to be confirmed using end-to-end tests rather than unit tests.

At this point, you’ll need to understand the automation test pyramid. If you are not familiar with it, Mike Cohn developed this concept a while ago. Its simplicity makes it a good, easy-to-remember rule of thumb when establishing your own test suite. The gist of the pyramid is that the more granular and isolated tests (unit tests) should run faster and cover the most parts; meanwhile, the more high level you get, the fewer tests you should have and the more integrated they should be.

(Image taken from: https://martinfowler.com/articles/practical-test-pyramid.html)

Hopefully these practical tips will come in handy as you test your code.

Ready to Become a Wizeliner? Apply Today!

Are you interested in joining our global team at Wizeline? We have open roles for engineers in Mexico, Colombia, Vietnam, and Spain — and plenty of opportunities to experience the joys of mentoring as well. Apply here.