12 Unit Testing Tips for Software Engineers
Unit Testing is one of the pillars of Agile Software Development. First introduced by Kent Beck, unit testing has found its way into the hearts and systems of many organizations. Unit tests help engineers reduce the number of bugs, hours spent on debugging, and contribute to healthier, more stable software.
In this post we look at a dozen unit testing tips that software engineers can apply, regardless of their programming language or environment.
1. Unit Test to Manage Your Risk
A newbie might ask Why should I write tests? Indeed, aren’t tests boring stuff that software engineers want to outsource to those QA guys? That’s a mentality that no longer has a place in modern software engineering. The goal of software teams is to produce software of the highest quality. Consumers and business users were rightly intolerant of buggy software of the 80s and 90s. But with the abundance of libraries, web services and integrated development environments that support refactoring and unit testing, there’s now no excuse for software with bugs.
The idea behind unit testing is to create a set of tests for each software component. Unit tests facilitate continuous software testing; unlike manual tests, it’s cheap to perform them repeatedly.
As your system expands, so does the body of unit tests. Each test is an insurance that the system works. Having a bug in the code means carrying a risk. Utilising a set of unit tests, engineers can dramatically reduce number of bugs and the risk with untested code.
2. Write a Test Case Per Major Component
When you start unit testing, always ask What Tests Should I Write?
The initial impulse is to write a bunch of functional tests; i.e., tests that probe different functions of the system. This is not correct. The right thing is to create a test case (a set of tests) for each major component.
The focus of the test is one component at a time. Within each component, look for an interface – a set of publicly exposed behaviour that component offers. You then should write at least one test per public method.
3. Create Abstract Test Case and Test Utilities
As with any code, there will be common things all your tests need to do. Start with finding a unit testing for your language. For example, in Java, engineers use JUnit – a simple yet powerful framework for writing tests in Java. The framework comes with TestCase class, the base class for all tests. Add convenient methods and utilities applicable to your environment. This way, all your tests cases can share this common infrastructure.
4. Write Smart Tests
Testing is time-consuming, so ensure your tests are effective. Good tests probe the core behaviour of each component, but do it with the least code possible. For example, there is very little reason in writing tests for Java Bean setter and getter methods, for these will be tested anyway.
Instead, write a test that focuses on the behaviour of the system. You don’t need to be comprehensive; create the tests that come to mind now, then be ready to come back to add more.
5. Set up Clean Environment for Each Test
Software engineers are always concerned with efficiency, so when they hear that each test needs to be set up separately they worry about performance. Yet setting up each test correctly and from scratch is important. The last thing you want is for the test to fail because it used some old piece of data from another test. Ensure each test is set up properly and don’t worry about efficiency.
In cases when you have a common environment for all tests – which doesn’t change as tests run – you can add a static set up block to your base test class.
6. Use Mock Objects To Test Effectively
Setting up tests is not that simple; and at first glance sometimes seems impossible. For example, if using Amazon Web Services in your code, how can you simulate it in the test without impacting the real system?
There are a couple of ways. You can create fake data and use that in tests. In the system that has users, a special set of accounts can be utilised exclusively for testing.
Running tests against a production system is risky: what if something goes wrong and you delete actual user data? An alternative is fake data, called stubs or mock objects.
A mock object implements a particular interface, but returns predetermined results. For example, you can create a mock object for Amazon S3 which always reads files from your local disk. Mock objects are helpful when testing complex systems with lots of components. In Java, several frameworks help create mock objects, most notably JMock.
7. Refactor Tests When You Refactor the Code
Testing only pays if you really invest in it. Not only do you need to write tests, you also need to ensure they’re up to date. When adding a new method to a component, you need to add one or more corresponding tests. Just like you should clean out unused code, also remove tests that are no longer applicable.
Unit tests are particularly helpful when doing large refactorings. Refactoring focuses on continuous sculpting of the code to help it stay correct. After you move code around and fix the tests, rerunning all the related tests ensures you didn’t break anything while changing the system.
8. Write Tests Before Fixing a Bug
Unit tests are effective weapons in the fight against bugs. When you uncover a problem in your code, write a test that exposes this problem before fixing the code. This way, if the problem reappears, it will be caught with the test.
It is important to do this since you can’t always write comprehensive tests right away. When you add a test for a bug, you’re filling in the gap in your original tests in a disciplined way.
9. Use Unit Tests to Ensure Performance
In addition to guarding correctness of the code, unit tests can help ensure the performance of your code doesn’t degrade over time. In many systems slowness creeps in as the system grows.
To write performance tests, you need to implement start and stop functions in your base test class. When appropriate you can use a time-particular method or code and assert that the elapsed time is within the limits of the desired performance.
10. Create Tests for Concurrent Code
Concurrent code is notoriously tricky and typically a source of many bugs. This is why it’s important to unit test concurrent code. The way to do this is by using a system of sleeps and locks. You can write in sleep calls in your tests if you need to wait for a particular system state. While this is not a 100% correct solution, in many cases it’s sufficient. To simulate concurrency in a more sophisticated scenario, you need to pass locks around to the objects you’re testing. In doing so, you will be able to simulate concurrent system, but sequentially.
11. Run Tests Continuously
The whole point of tests is to run them a lot. Particularly in larger teams where dozens of developers are working on a common code base, continuous unit testing is important. You can set up tests to run every few hours or you can run them on each check-in of the code or just once a day (typically overnight). Decide which method is the most appropriate for your project and make the tests run automatically and continuously.
12. Have Fun Testing!
Probably the most important tip is to have fun. When I first encountered unit testing, I was sceptical and thought it was just extra work. But I gave it a chance, because smart people who I trusted told me that it’s very useful.
Unit testing puts your brain into a state which is very different from coding state. It is challenging to think about what is a simple and correct set of tests for this given component.
Once you start writing tests, you’d wonder how you ever got by without them. To make tests even more fun, you can incorporate pair programming. Whether you get together with fellow engineers to write tests or write tests for each other’s code, fun is guaranteed. At the end of the day, you will be comfortable knowing your system really works because your tests pass.
And now please join the conversation! Share unit testing lessons from your projects with all of us.
