Unit testing can be one of those polarizing topics in software development. But Joe DeMeyer says good unit testing allows you to explore products deeper, lowers your estimate, improves quality, and maintains productivity pace. Here, he talks about how you can get your developers and business team on board.
Allow me to give a suggestion: Make unit testing a part of every test strategy. Add it in with exploratory and tool-based techniques, but make sure you add it. Good unit testing allows you to explore products deeper, lowers your estimate, improves quality, and maintains productivity pace.
I don’t expect you to design or execute the unit tests, but having unit testing as an explicit part of your test strategy says you depend on it and expect it to help deliver quality products.
When you discuss strategy, explore the multiple benefits of unit testing. It can:
- Evaluate basic functionality and requirements, allowing you to explore deeper and more diverse scenarios
- Reduce your estimate because the time spent evaluating requirements is now better spent in other scenarios. The time spent in requirements-based testing can be part of the development estimate
- Help you explore areas that are difficult for black-box techniques. The tester collaborates with the developer to probe those areas and reduce defects that are difficult to locate or reproduce
- Reduce defects to help maintain productivity pace
So, you may be asking: Why doesn’t everybody do it?
Unit testing can be one of those polarizing topics in software development. Many developers do not plan, create, execute, or record their testing. The ensuing defects erode their credibility, cause delays in projects, or cause focus to shift away from product development.
If your project is not seeing adequate unit testing, here are some thoughts on its benefits and ideas you can use to collaborate with developers.
Getting Your Team On Board with Unit Testing
For the purpose of this article, I discuss unit testing in the context of software development, and I think of unit testing as the same thing as development testing, low-level testing, or component testing. I submit that unit testing is any action a creator makes to check a change they made, and it is not necessarily automated. The unit test of a change can be a review or a demonstration of functionality—or, preferably, both.
Under this definition, notice that I don't constrain anyone to just source code. There are many files that are necessary for an application to operate successfully. The application file itself, component files the application may reference, configuration files that direct behavior, database files, schema files, and debug files work together to deliver functionality. Each of these files can be impacted by a change to the source files used to construct the application, so any change to any file is a candidate for a unit test.
Any change? you may be asking. Joe, if I change a single character in a configuration file, you are suggesting that a unit test is necessary?
Under my definition above, yes. But it depends. For me, it depends on who made the change, the scope of the change, and the context of the change.