How to deal with those TDD breaking people?

Question

Personally I really prefer Unit Testing and write them for "good" coverage. (let's say I try as hard as possible to write good tests ;)

As usual some time later someone different needs to add some features to the code (add methods to classes and so on). He doesn't break those written unit tests but refuses to write additional (which would cover those additional features of the code he wrote). This leads to a big hole in the tdd process (and even worse maybe a broken window effect)

anything I can do to make him write those tests? how do you deal with those people?

Answer 1

Aside from a company policy and repercussions from their manager, there's not much you can do about it. Maybe there's some way in your Source Control tool to require that anything public have a unit test that's flagged as such.

You could even write a macro that's part of your build process that looks for anything marked PUBLIC (I'm a VB guy), and then checks to ensure that, somewhere in the solution, there's a unit test with a code comment that sufficiently links it. Failing to have an associated unit test breaks the build and sends out an email to the whole dev group that sufficiently shames said non-tester.

Maybe I'll set that up here, now that I think about it...

Answer 2

If you have a build process you could use a tool like NCover or PartCover and fail the build if the coverage isn't sufficient.

Answer 3

Track code coverage with some tool, e.g. for Java there is Emma, and generate a report for management with each release. When numbers are too low or go down management should investigate the causes.

Answer 4

Pair Programming. With two people working on something, programmers are much less likely to take shortcuts like this.

Answer 5

Remember that TDD isn't primarily about generating good unit test coverage; it's about motivating good design first, about ensuring that the code you write does what you expect second, and about providing a body of high quality tests third.

When another programmer extends a class without writing tests, they miss out on these benefits, and you should feel pity on them. But when you work, you will continue to work the best way you know how (test first) because you know that it you get decoupled code that is easy on the consumer, and that your code does what you expect.

The biggest pain for you is that you have to be careful about what you refactor: if you are refactoring code that is under tests, you can go fast, and design will quickly and safely improve. If you are refactoring code that is not tested, you should be extremely cautious about refactoring it (perhaps only using reliable automated tools to do so) or add the tests.

In the end, you will continue to benefit from your use of TDD, because you produce clearer, correct code, faster, while your TDD-impaired colleague will suffer.

Answer 6

Play the video of the "Don't tase me bro!" guy as a warning

Answer 7

Don't approach this as a confrontation! You're asking how to force a coworker to do something s/he clearly does not see any benefit to. You can't make someone use TDD - as you've already seen yourself. The only way a developer will embrace TDD is when someone else helps them reach that "aha!" moment. Be respectful as one colleague to another and show him/her through your actions and be positive in wanting to help him/her get over the mental hump.

Answer 8

Teach your co-workers how to do TDD, so that they can turn their brains upside-down (I had that feeling when I tried TDD the first time) and begin to write tests first.

Once I did an experiment with a programmer friend of mine, who did not know TDD. I came to his house and we started writing Tetris using TDD (we spent about 6 hours that day and progressed nicely). First I wrote a test method, and then he wrote the code to pass the test. In the beginning he was slightly opposed to writing "the simplest thing that could possibly work" (such as hardcoding the return values in the first trivial tests) and not planning much ahead, but anyways he sucked it up and followed my instructions. As we progressed, it appears that slowly he begun to understand what was the point in it all.

Answer 9

Lead by example. Your coworker may simply not understand how to use TDD appropriately. Next time it happens, write a unit test for them. Make sure to point this out to them: "Hey, I noticed you added x feature to the program without a unit test, so I wrote one for you and put it here." This way they have an example and won't feel embarrassed by having to ask how to unit test.

Only do this once or twice. After that, make sure to mention any future occurrences. You'd be surprised at the difference a polite "Hey, you didn't write a unit test for function y, it'd really help me out if you'd write one for me" will make. Remember, you're goal isn't to try making them write tests. It's to make writing tests less of a hassle than not writing tests.

If the above doesn't work, it's time for a discussion with management. You've already tried to resolve the situation amicably, so it's time to consider a less-than-amicable approach.