12 Unit Testing Tips for Software Engineers
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.
