How to evangelize unit tests in the organization?

Question

I love unit tests because I truly believe they promote code quality and design best practices.

The problem is that many of my team lead colleagues think they are waste of time. We already had a few unit tests initiatives that failed due to team leads reluctant attitude. They argue that maintaining the tests doesn't worth the trivial bugs the tests detect. I prefer not to be dragged to this argument, as I said I love unit test because of their effect on the code quality and unfortunately not everyone care about code quality.

I do lead by example, my team is leading in that aspect, but I feel it's like a drop in the ocean.

How would you evangelize unit tests in your organization?

Answer 1

Well, you could start using them for you own code and evaluate the effect on the code quality in the end. If it has significant effect, the others will follow eventually.

Answer 2

Show them a bug that would have been very embarrassing if it had made it into a release, but was caught by a unit test.

Answer 3

If you don't have any management clout yourself:

• Lead by example.
• Accumulate hard numbers that show the resulting better quality, quicker development and lower bug counts that you produce.
• Point these out at every occasion to both developers and management.
• Good occasions are development crunches where people have to work overtime to finish features, fix bugs, and then fix more bugs they introduced due to the lack of unit tests, and finished releases that turn out to contain nasty bugs. Especially when they could have been caught by existing tests which nobody ran.

I did it this way in my current project (with tentative management support). It took well over a year, but unit tests are now an accepted part of the SOP.

BTW, having a continuous buld server that runs the tests automatically is pretty much a required part of the strategy, since it makes it that much more effective than having to tell people to run the tests manually all the time.

Answer 4

Just use them for your own stuff and when you get the chance to collaborate explain your intent through unit tests then explain to them you've not only just tested but designed as well. It may take a few of these sessions but eventually your peers will have a lights on moment.

Answer 5

There are two basic reasons to do unit tests: reduce bug count and make it easier to implement new features without breaking old ones. There is a lot of literature on the web that speaks to how unit tests and test-driven development can lead to fewer defects. It would be even better if you could demonstrate using your own defect tracking that your unit-tested code has fewer defects from the beginning.

One problem is that unit testing does take more time -- at least initially. As the code grows, however, the amount of time to introduce new features remains reasonably constant with unit tested code, whereas it starts to increase with non-unit tested code because you begin to introduce breaking changes and then have to spend time tracking those down. With unit tests, you know immediately when you introduce a breaking change, what the change breaks, and usually where to fix it.

In an organization that values speed over quality, however, this argument typically fails as any practice that slows down development, even if only at the beginning, is frowned upon. Perhaps, what's really needed is an organizational change to value quality more highly.

Answer 6

We had unit tests, and they were often broken because they weren't being run.

This all changed when I made the continuous integration builders also run the unit tests - when people were being emailed about unit test failures they started fixing them, and keeping them working.

Answer 7

If your team-mates despise unit tests, it will take a lot of work by yourself to promote the tests.

First you have to use them yourself for your own code and to reveal bugs in other peoples code.

Secondly, it will help you nothing if you use unit tests and have no hard data to back up your claim that they increase software quality. Try to install some kind of metric like bugs per coder per month or something like that. Collect this data over a few months and show that the code that us backed up by your unit tests is less error-prone than the un-tested code others wrote.

And a third point can be to make testing more accessible to colleagues that are sceptical but interested. Develop some frameworks to quickly generate test data with a few lines of code or work on a code generator for often-used tests. Show the other developers how easy it is to write a unit test, and how fast it can be executed.

You could also try to do "guerilla continous integration". Set up a task on your computer to continously check out source code, build the system, and automatically run the test cases. Tell your collegues when you have found a bug in their code with one of your tests. They will wonder how you could find the errors so quickly and perhaps see that it is good that these bugs have not reached the customer.

This all will take time and dedication if the atmosphere in your team is contra unit tests. It could take several months or even years until people realize that writing tests can make their life easier. The last option could be to realize for yourself that you are working for a company that does not value quality as highly as you, and that you could look for an employer with another mindset. But sometimes, the battle is worth it.

Answer 8

You might want to have a look at "Brownfield Application Development". Forget the fact that the cover says "in .NET" - most of the book (at least, when I read the last draft, about 50% complete) focuses on the people/conceptual sides - in particular how to influence (separately) management and developers, and how to approach unit testing etc.

I recommend it.

Answer 9

No, no, no, Unit testing is not the be all and end all of testing. In my time managing projects I've come across scenarios like this:

Developer: Why is the customer complaining about this bug? All the unit tests in the area passed

Me: -looks at unit test- yeah but the unit test didn't cover xyz scenario well....

OR

Me: -looks at unit test- no, you created the test wrong, here's the flaw...

Unit tests are only as good as the developer creating them...

Having said that, they're a great way to reduce bug count, but if your organization isn't accepting them, maybe there's a practical reason why. Besides you can't expect Rome to be built in a day and have an entire organization adopt to you overnight. Just produce great results and others will follow...

Answer 10

unit testing is another bandwagon people are jumping on as if it is a magic bullet that will magically fix all bugs. It won't, it doesn't.

Now, if your developers are only putting trivial bugs in your code, I'm impressed. I'd say that these bugs were being caught by whatever other testing strategies you have in place and that is working well. So, in your case, you do not need unit testing. Adding them would only distract you from the current excellent job you're all doing.

System testing can produce as good, if not better, test coverage. If you have that, the benefits of unit testing (eg regression tests) will just be caught later on, so adding unit tests would just be redundant.

If you are really concerned about code quality and testing, then take the current test regime you use and contribute your energy to making that better, don't worry over getting unit tests into your group.