Bloggo back to the blog
G(r)ood testing 25: Tips for how to boost Unit testing as a Functional Tester
The test automation pyramid
When automating your tests its quite common to refer to the Test automation pyramid.
The layers in the pyramid represent the test levels and the width of the pyramid the relative amount of automated tests for each test level. With Unit testing at the base, the illustration tries to show that it’s better to have a lot of automated unit tests than to emphasize automated end-to-end test (that are run via the UI). The reason for this is that the later are more brittle. They are harder to maintain, more difficult to automate and most likely take more time to execute. So if you strive for quick and easy feedback loops that warn you as soon as anything is broken in the system, its best to ensure that good unit testing is done.
Struggling with our unit tests
Unfortunately, many organizations are still struggling with setting up their unit tests. Causes can be various. Some teams are trying to create a good test set but inherit a huge backlog of never written unit test. Other teams are working on a legacy system that makes it hard to create them, while others succumb to the pressure to deliver functionality and never get to unit testing at all. Whatever reason, Unit testing still seems to be the domain for developers and many functional testers find it hard to get involved and improve the way unit testing is being done. Many functional testers lack sufficient development knowledge and end up automating functional tests instead. But like I said, automating the tests higher up in the pyramid is less efficient, so this is not the best strategy. Since I have seen many testers struggle with this, I wanted to define some tips on how you, as a functional tester, can introduce unit tests or improve the quality of it.
Putting our minds together
Last September I joined the 21st testing retreat which was held in France. The testing Retreat is an annual peer conference where senior testers from various countries meet and spent their weekend together to talk about the profession. During the weekend I explained the challenge to my fellow participants and suggested we’d put our minds together. During the interactive brainstorm that followed we concluded that the best way to improve Unit Tests and to bridge the gap tester and developer is adopting agile. Agile teams are multidisciplinary and work together on the same goal. This ties the tester and developer together and bridges the gap there may be between both disciplines. Additionally, we defined the following tips:
Tips for boosting Unit testing
- Focus on doing useful tests (tests deliver information) rather than discussing whether the tests are unit tests or functional tests
- Ask the developer for Help (or offer him to help?), rather than telling him he needs to do UT
- Pair the tester and developer together while defining the tests
- Demonstrate the damage of not doing UT – E.g. showing that late found defects slow everyone down
- Organize coding Dojo’s where you put unit testing on the agenda
- Introduce test design techniques to the developers
- Get an understanding about the build and deployment process
- Embed Unit tests in the check-in and deployment cycle
- Include a definition of a unit and its size in the coding standard
- Add Quality guidelines to the coding standards
- Include Unit testing in the DOD
- Use Stubs and drivers to mock adjacent units and test them independently
- Create hooks and API’s that enable efficient testing when necessary
- Use gamification – e.g. introduce prizes like a best unit tester of the week mug to reward developers that do good unit testing
- Include checking the UT test in the code review
- Start with unit testing before you start with TDD
- Explain the developer what test you want to do, do the developer can think about how to refactor the code in order to make the test obsolete
I personally like the last tip very much, because it reminds me that we want to do useful tests regardless of their name and it emphasizes that our true end goal is not testing at all. We need to deliver value by making quality code. Unit testing is not a goal on its own, but a good means to an end.
Thanks Debra Friedenberg, Declan O’Riodan, Gwen Stewart, Jean-Paul Varwijk, John Fodeh, Mette Bruhn-Pedersen, Mieke Gevers, Nathalie Rooseboom de Vries van Delft, Neil Thompson, Phil Isles and Rik Marselis for your input.