Question

Most developers appreciate the worth of automated testing. However, it can be a great leap from there to convincing them that its worth their time coding unit tests (as opposed to integration tests, which are the domain of testers), be it with TDD or some other process.

What arguments do you use to convince developers that they stand to benefit from having a battery of unit tests in place?

Answer 1

This is a tough one because what you really have to do often is convince developers that they actually care about quality.

Something that has worked for me is to scan the bug database for bugs that I felt would have been found by minimal unit testing (usually in at least two components so it doesn't look like I'm beating up on one developer). (when I did this, I actually wrote the unit tests to just to have more proof on the concept).

Then I prepared a short speech / presentation / elevator speech that showed two things:
1 - the bugs that should have been caught by UT, and
2 - the types of bugs I WANT to be finding (examples from the bug db help here)

Another thing that works well (with and without the above) is to find a single dev or dev team who wants to do TDD or unit testing and have them pilot an effort. A case study on the pilot is also super-beneficial in this case.

Answer 2

If you want developers to write unit tests, sell them on the things that developers benefit most from: Refactoring and design improvements.

Refactoring: If developers have unit tests, they can clean up the nasty parts of the code without fear. Goodness knows how many times I've seen a development team say, "If we clean that up, We'll have to ask the testing team to re-test everything; Better leave it." No one likes to make that decision, and a strong unit test suite can allow you to fix code uglies without fear.

Design: "TDD is not about testing". I hear that all the time. It's a design methodology. If programmers care about having a flexible, decoupled design, TDD will get them there. It will also produce a comprehensive unit test suite.

Nagging developers about "you should have caught this bug in your (nonexistant) unit tests" will just make them cranky. Sell them on the benefits that they'll get inside the code base, where it hurts them the most. You will enjoy not having to file a bunch of "fails on negative numbers"-style bugs, but that's not what the developers care about.

Answer 3

I like Alan's answer a lot and I'd suggest starting there.

To add to it: consider the financial implications of lax unit testing vs. thorough unit testing as well, and put together a quick back-of-the envelope business case.

Incidentally, this approach is not recommended for the feint of heart; it is politically-charged and could wind you up in hot water.

If it costs, on average, say $500 more per bug to fix in a later stage of testing than it does during unit testing (see this question for a discussion on that topic; reliable stats here can be hard to come by), and there are 1,000 defects a year slipping through Unit Testing that "should have been" caught during Unit Testing*, inadequate Unit Testing would be costing the company approximately $500,000 / year. If 1,000 hours of developer time would reduce the number of such defects and, for the sake of nice round numbers, each developer had a loaded hourly cost of $100 / hour, $100,000 going towards extra Unit Testing would save the company $250,000.

Do you take those figures to an individual developer? To your CIO? That's a different question for another day...

Answer 4

I think most developers do care about the quality of the work they produce, but for whatever reason they may not do unit tests or the unit tests may be superficial. Along with Alan's suggestions, I would suggest that (especially in an Agile environment) testers partner more closely with developers to help them design better unit tests that are not over-bearning and can be easily integrated into the developers workload.

However, my favorite starting point in getting developers to think about unit testing is to either get them to read, or summarize the section of chapter 1 in Pragmatic Unit Testing called "Excuses not to unit test" which also provides counter-arguments. (My favorite is something along the lines of 'I get paid to code; it not my job to test.' The rebuttle to this argument is, 'Devs get paid to write code that works.'

Answer 5

For an opposing viewpoint, see Chris Ashton's post It's OK Not to Write Unit Tests

Are you the development manager? If not, tread lightly. If you're a test manager or tester, then it may be perceived as arrogant to assert that you know better than the experienced development group how to develop software. These are competent people, skilled at their craft, who are aware of unit tests and made a decision not to spend time on them.

Develop an elevator pitch, as Alan Page suggests.

Identify the key influencers and get them on side. Write some unit tests yourself and demonstrate running them.

Ask the developers if they see value in writing unit tests, and listen respectfully to their objections.

Ensure the developers have the tools, skills, time allocated, and expectation to do this.

Consider incentives and rewards for writing unit tests. Hold a contest with a prize to get people hooked on the green bar.

Collect metrics on what code has unit tests, set agreed-on targets, and measure your progress as part of your test reporting.