Software Testing is hard. The intention of unit testing is to make it easier through automation. In practice however, unit testing often causes even more pain than software testing. Learn how to cure this pain in this article!

The Pain

A created unit test can be executed as many times as you want. With the additional benefit of getting feedback early in the development process. At least in theory. However, practice shows that unit testing simply shifts the pain of testing from a professional software tester to the developer, whose profession is to write code, not tests. In it’s essence, this pain of unit testing can be broken down into three problems:
1. Divide & Conquer gone wrong As an economy, whe have progressed in the last century by dividing tasks into different work profiles. As one result, when we identified the crucial issue of testing software, software testers emerged to focus on fix this issue. They have developed many practices (see ISTQB) over the years, and most testers are trained in doing the best in their job, full-time. However, with unit testing, we shift this responsibility of software testing back to the developer. Whereas this develoeper might know the underlying code the best, her job is to write code, not tests. As a result, most unit tests are developed with poor methodology, and even poorer motivation – simply because the person writing the test wanted to get over with this burden to continue writing code.
2. Code Coverage – so what? Too often, developers write unit tests to satisfy some code coverage constraints. Which makes sense in theory, because code coverage tells you. So if you have 100 % code coverage, you know that your system works. In practice however, the only thing that 100 % code coverage produces is a whole bunch of unnecessary test cases that noone will maintain, thus will be burried in some code graveyard that noone wants to have a look at once the underlying software changes. The calculation of code coverage has many flaws (see an example here: Limits Code Coverage), which means that it essentially doesn’t tell you what it promises to. Whereas code coverage gives you a good first impression of whether you should still write some more tests, it does not tell you whether your tests actually cover enough (or all) desired functionality of your software.
3. Never change a tested system. One trap that many developers fall into is believing that once a unit test is written, they can re-execute it for the rest of their (or at least the software’s) life. However, a unit test is code, which compares the functionality of your software code with the expectations derived from the requirements of the software. But what if the requirements change? Or the structure of your software code changes? Both cases require you to adapt all of the relevant unit tests. In agile environment with frequently adapting requirements, this is the actual pain in unit testing! Usually, it leads to unit tests not being updated after some time, and again switching to manual testing (or no testing at all) for legacy parts of your software.

The Cure

1. Do Unit Testing right. Use the right methods to maximize the impact of your unit tests, while minimizing the effort you need to create and maintain your tests. Read more here: 2 methods that help you save 60 % of your effort in Unit Testing . Write clean code (what does this mean for unit testing? See here: Clean Unit-Testing, What it takes to make good Unit-Tests )
2. Understand the benefits of Unit Testing. The purpose of unit testing is not to satisfy some code coverage constraint, but provide value to software developers. This value can go beyond executing the tests to find bugs in your implementation (see 5 things you can learn from executing your test cases). Anyways, you should not write a single unit test, before you know why you are actually unit testing. I’ve written on that here Why you shouldn’t write a single unit test, before you know how to do unit testing right 
3. Agile Unit Testing. The best way to cope with constant change is to expect things to change from the beginning. Whereas this mindset is starting to get accepted in software development in general, it is still non-existing for unit testing. But what does expecting change even mean for writing unit tests? You could consider that when writing your unit test code, by applying an architecture that optimizes for adaptability (if you do, have a look at this checklist first: The Ultimate Checklist for Better Unit Testing). You can also simply use tools that help you manage test cases, by taking over the whole coding part. The right tools provide you with an interface that is optimized for finding and adapting unit tests.
What do you think of the pain in unit testing? What are your experiences in curing it? Let me know in the comments section below!

Vector created by storyset – www.freepik.com

Leave a Comment

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.

Privacy Settings saved!
Privacy Settings

When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.

GetResponse, Google Analytics

We use LinkedIn Insight for marketing purposes. You can disable these cookies.

We use Google Analytics for marketing purposes. You can disable these cookies.
  • __utmz
  • __utma
  • _ga
  • _gat

We use GetResponse for marketing purposes. This service cannot be disabled, otherwise the website functions will be limited.

Decline all Services
Accept all Services
Get Free Access Now to
9 eBooks!
All about Automated Software Testing
Proven experts
Learn to save up to 75% of your test efforts
Get Free Access Now!
Get Access Now! & Save 50%
Personal Trainer FREE Nutrition Custom Workout App
Get Access Now!
eBook Download
Enter your details to get your free ebook!
All about Automated Software Testing
Download Free Ebook
Lorem ipsum dolor sit amet, consectetur adipiscing