How to deal with those TDD breaking people? [closed]

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

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.