top of page
  • Writer's pictureCraig Risi

Why Testers Should Focus on Unit Tests

Testing has changed from a discipline that was largely manual and isolated from the rest of the development, to one that is highly technical, focuses on automation and requires closer collaboration with testers. Sadly, I have found that this change has not been implemented in many South African tech companies. This article will explain why it is important to understand and effectively implement unit testing, as well as provide tips for writing unit tests that ensure both testers and developers deliver higher quality code.

When I first made the transition from software developer to tester, the big trend was to keep testers and developers separate to ensure the independence of the testing team. This concept of “not marking your own homework” was seen as a strong purveyor of quality, but over time many companies have realised that this actually created more problems than it fixed. For instance, as a tester, I would end up focusing on how to find faults in the software, rather than how to build it better. It also meant that my goal as a tester was not aligned with the developers’ which naturally meant that I would work separately from them.

These days I’ve learnt that the best way to build high-quality software is to get it right at the design level. The best way to do this is by designing your software in a manner that suits your testing strategy and allows for small, easy-to-maintain components that allow for decent unit testing. It is also important to test as close to the code as possible by playing in the unit test space, because this is where the majority of testing efforts need to be focused.

This is why I will spend some time discussing how to get the design of your unit tests right, as well as how to think about testing.

Why should testers focus on a unit test?

As a tester, one of the first mindset changes that I required for unit testing was to shift focus from the big picture integration of the software, to the details of the code. By doing this, I saw how systems can be better mocked and isolated to allow the unit test to be effective.

If you are a tester and have not made the transition to intensive unit testing, this might be because you are not yet convinced of its benefits over-and-above the regular high-integration test coverage. Perhaps knowing the some of the benefits will help get you there:


The most important benefit is that it will force collaboration between developers and testers. So, if you’re a tester, and you wish that you could get more involved in how the software is designed, then getting involved with unit testing is the best place to start.

Ever since I’ve been involved with the unit tests, both the developers and I work closer together on the quality of the product - which is always a good thing!

It also ensures that the development team hits the required test coverage needed to reduce the integration testing that can be done elsewhere. This is because the code often works the same whether it is tested at a unit level or integration level, so you can reduce effort later by testing it earlier.

Test driven development (TDD)

TDD is a big buzz word that calls for the tests relating to a developer’s code to be clearly identified and written before they’ve finished their development work. This makes it easy for them to know what their code is supposed to do and the parameters it needs to pass in order to be deemed good enough. Unit tests help with TDD by making it easy to associate lines of code with tests and thereby identify exactly which parts of the code are not behaving correctly.

This helps developers when they want to submit their code and know that it’s met all of the relevant criteria almost immediately. It also forces developers to think more clearly about what they’re designing, as the guidelines and criteria to pass are clearly understood.

Finding bugs early

Not only are unit tests faster to execute, but it also means that defects are found the moment code is pushed into the pipeline. This means that the developer can see the failure straight away and get it fixed before the code even makes into any form of integrated test environment. It’s like I’m not just automating the test, but automating the whole defect life-cycle too.

Reducing costs and duplication

Faster execution and early error detection are going to save efforts later in the development cycle, making it cheaper for everyone. This reduces the duplication of covering the same scenarios at an integration level that developers cover in their unit tests.

Documenting the code and increasing traceability

Another benefit, which should appeal nicely to testers, is that unit tests make it easy to identify what the code does while allowing for traceability – which is vital to ensuring software quality.

Most coding repositories will allow software requirements to link up to unit tests. This helps testers track coverage a lot easier without them needing to do all of this themselves.

Improved ideation

One of the things that I have found with testing is that not everyone does a good job at it. Not all developers have the knack for thinking of good test scenarios, so the quality of code and tests can vary greatly. By getting involved in unit tests and focusing on isolated use cases, I was able to apply my testing mindset to identify better test scenarios. This meant that I could cover more tests at a unit test level, but also that there was less to do later on. Thus, eliminating the most horrible testing crunches that are often part of any sprint cycle.



Thanks for subscribing!

bottom of page