Hosted by:
Unit testing expertise at your fingertips!
Home | Discuss | Lists

Developers Not Writing Tests

The book has now been published and the content of this chapter has likely changed substanstially.
Please see page 263 of xUnit Test Patterns for the latest information.

Developers aren't writing automated tests.


We hear that our developers aren't writing tests. Or maybe we have observed Production Bugs (page X) and we have asked "Why are so many bugs getting through" and have been told "Because we aren't writing tests to cover that part of the software."


If the team isn't writing automated tests for every piece of software "that could possibly break", it is mortgaging its future. The current pace will not be sustainable over the long haul because the system will be in test debt. It will take longer and longer to add new functionality and refactoring of the code to improve the design will be fraught with peril (therefore it will happen less and less frequently.) This is the beginning of a trip down the proverbial "slippery slope" to traditional paranoid, non-agile development. If that is where we aspire to be, we should stay the course. Otherwise, it is time to take action.


Cause: Not Enough Time

A probable cause is that developers are having trouble writing tests in the time they are given to do the development. This could be caused by too aggressive a development schedule or them being told "don't waste time writing tests" by their supervisors or team leaders. It could also be caused by them not having the skills to write tests efficiently and not being given the time to work their way up the learning curve.

If time is what they need, we'll need to adjust the project schedule to give them the time. This should only need to be a temporary adjustment while they develop the skills and test automation infrastructure that enables them to write the tests more quickly. In our experience, once developers have internalized the process, they can write the tests and the code in the same time as it used to take to write and debug just the code. The time spent writing the tests is more than compensated for by the time not spent in the debugger.

Cause: Hard to Test Code

Another common cause, especially with "legacy software" (defined for our purposes as any software that doesn't have a complete suite of automated tests) is that the design of the software is not conducive to automated testing. This situation is described in more detail in its own smell section, Hard-to-Test Code (page X).

Cause: Wrong Test Automation Strategy

The cause may also be a test environment or test automation strategy that is leading to Fragile Tests (page X) or Obscure Tests (page X) that take too long to write. We need to ask the "five why's" [TPS] to find the root causes. Then we can address those causes and start getting the ship back on course.

Trouble-Shooting Advice

Project level smells such as Developers Not Writing Tests are more likely to be detected by a project manager, Scrum master or team lead than by a developer. As managers, we may not know how to fix the problem but our awareness and recognition of it is what matters. This allows us to ask the development team questions about why they aren't writing tests, in which circumstances and how long it is taking to write tests when they do write tests. Then we can encourage and empower them to come up with ways of addressing the root causes so that they are writing all the necessary tests.

We'll have to give them our full support in carrying out whatever improvement plan they come up with. That support will have to include the time to learn the requisite skills and build or set up the necessary test infrastructure. And we shouldn't expect things to turn around overnight. We might set process improvement goals for each iteration such as "20% reduction in code not tested" or "20% improvement in code coverage." The goals should be reasonable and high-enough level that they encourage the right behavior as opposed to just making the numbers look good. (A goal of 205 more tests written could be achieved without increasing the test coverage one iota simply by splitting tests into smaller pieces or cloning tests.)

Page generated at Wed Feb 09 16:39:51 +1100 2011

Copyright © 2003-2008 Gerard Meszaros all rights reserved

All Categories
Introductory Narratives
Web Site Instructions
Code Refactorings
Database Patterns
DfT Patterns
External Patterns
Fixture Setup Patterns
Fixture Teardown Patterns
Front Matter
Result Verification Patterns
Test Double Patterns
Test Organization
Test Refactorings
Test Smells
Test Strategy
Value Patterns
XUnit Basics
xUnit Members
All "Test Smells"
Code Smells
--Obscure Test
--Conditional Test Logic
--Hard-to-Test Code
--Test Code Duplication
--Test Logic in Production
Behavior Smells
--Assertion Roulette
--Erratic Test
--Fragile Test
--Frequent Debugging
--Manual Intervention
--Slow Tests
Project Smells
--Buggy Tests
--Developers Not Writing Tests
----Not Enough Time
----Wrong Test Automation Strategy
--High Test Maintenance Cost
--Production Bugs