The definition of unit testing is simple: you test the smallest piece of your software that can be isolated. It can be as small as a single line of code or as big as a module. This is, however, one of the times where smaller is better even when working on a large-scale project.
Software unit testing is usually done by developers themselves. Indeed, they may not have the time or quality assurance expertise for a proper unit test plan. Devs, however, know their own code better than any QA specialists could understand it. Testing code before it is passed on to the quality assurance people has been a best practice for years.
Advantages of unit testing
The purpose of unit testing can’t be narrowed down to just one thing. Having developers go over small units of code has multiple advantages:
- Improves understanding of the codebase by the developer. This is largely relevant for new additions to the team. No matter how much documentation you give to new devs, practice always makes things easier.
- Self-sustainable, meaning neither the devs nor QA specialists wait for others to finish their code first
- Facilitates good regression testing or rather a good follow-up to regression tests. If they reveal a problem, it is much easier to isolate the cause and resolve the defect when small pieces of code are covered by individual test cases
- Improves the quality of code. Not involving devs in testing is flawed on many levels, and depriving the project of better code is one of them. Hasty rewrites and last-minute debugging contribute to tech debt, making the software prone to crutches over real solutions. Regular testing in small chunks brings greater attention to detail and doesn’t let flaws pile up
- Saves time and money. It’s simple: good automated unit testing means that a lot of issues are spotted without human effort. A one-time investment plus some maintenance considerably free up schedule of devs and testers
Try a collaborative ALM tool for devs and QA
Unit testing techniques
The unit testing techniques correspond with general testing techniques.
- Black box technique covers software behaviour from users’ point of view: the QA specialist is unaware of how the solution is designed
- White box technique refers to testing with knowledge of how the software was designed to work
- Grey box technique is a middle-ground: it tests user-facing functionality like black box testing would but done with the knowledge of the solution’s architecture
As for how unit testing is done, both manual and automated approaches are thriving. Just like with other types of testing, the latter is good only if you know why you’re automating QA. The role of developers in unit testing means that there’s a QA workload for non-testers, so increased automation could be more cost-effective than ever.
Interested in different types of testing?
Read our article on user acceptance testing definition, usage, and challenges
Getting devs invested into unit testing can be challenging. Here’s how Alan Mellor, the author of Java OOP Done Right with 30+ years of software engineering experience, describes the benefits for devs:
A unit test always has three parts: Arrange, Act and Assert.The last two are always one-liners. They also express a piece of design thinking that you’ll be familiar with: the API of your code and how it talks with the caller. Unit tests really only get tough to write in the arrange step. This is where you create the graph of objects and initial states needed to run the test. If your code has got into a tangle, this can be really difficult to do. This is your first sign that your design sucks.
You’ve most likely kept bolting pieces together, tinkering about and doing too much in one step. We all do. The answer is to redesign that part of code. Split apart some objects so each one does a smaller piece of work. This reduces the complexity of the Arrange step and of the production code as well. By writing tests earlier, you shorten the feedback cycle. You become aware of the mess sooner. You also start to get an intuition about how to design your code correctly split up in the first place, which also makes it easy to test.
Here are some unit testing ideas so you can learn from trial and error done by others.
- Apply the “Given/When/Then” protocol to organising unit tests. This approach is also known as Arrange (the test setup), Act (on the unit for the test), Assert (verify the outcome) described by Alan Mellor
- Keep tests simple. For example, if you try to account for all possible inputs in one test case, you may have very well written a test that largely repeats the code being tested.
- Get a good naming convention going. Navigating all your tests can be daunting at times, and it’s even more so when it’s developers who are making tests as well. Getting on the same page with naming goes a long way
aqua tool for unit testing
Test management systems and Application Lifecycle Management solutions like aqua are not quite used for unit testing. Developers write tests and execute them in IDE (integrated development environment) that is not linked to the test management solution’s server.
On the other hand, a bug reporting tool helps achieve and reinforce many concepts that unit testing strives for. A good example is tracking test coverage. aqua has provided that for years, but we have just visualised it with a neat column on the Requirements screen. There are plenty of other features promoting collaboration between devs and QA, much like what unit testing does.
Unit testing is a great asset for any software project. Getting developers to test their own code early has both short-term and long-term benefits for your company. While test management solutions have little to do with unit testing, they help you cultivate the same Development–QA collaboration, thoroughness and conciseness that unit testing entails.
Reach 90%+ test coverage