Derik Whittaker

Derik

following on from your last post, where you friend (I'm hoping not your colleague ;-) tests are better than no tests - absolutely.

Not sure how tests ensures cleaner code though.  It may 'encourage'  refactoring, but it certainly doesn't 'enforce' it.

As a TDD'er though, I would say that doing the tests first gives you more than SoC.   It helps you design by defining your interfaces.

Just my two pence worth.

I agree with Derik - do tests in a way that you like, don't follow purists adviced if you are not comfortable with them.

AndyB - I see that you are closer to tdd zealots. If you saying "interfaces" means API then it is partially true. But only when you drop typical test writing. When you are writing only those blessed multiple small tests then benefits for API are rather poor. If you break the rule of small tests ONLY and start writing larger  (possibly redundant) tests then you API "design" can have benefits from it. But then you are outside of the Right Way of TDD.

Good API design comes from "code/class" interaction then from working code.

My experience isn't that testing encourages or enforces re-factoring--it just ensures the current level of quality despite of re-factoring.

TDD "mandates" test first, but it doesn't preclude testing (in all forms) throughout the rest of the life-cycle, which is what Derik is saying.

I think many people are doing themselves a disservice in that they're testing efforts are the only place they're implementing SoC, IoC, etc...

There was an interesting lightning talk by Johannes Link (a well known Agile coach here in Germany) at last years XP Days Germany. He reported that he could classify the  teams he had coached and came back to after a few weeks into two classes:

One that had code coverage of over 80% and the whole team writing tests.

The other had only a few developers writing tests, code coverage being around 50%.

Now the interesting part is that he said that those two different results closely correlated to whether the team had adopted a test first approach or was writing tests after the production code.

This is consistent with my own observation that writing tests first is actually much easier - and more importantly much more *fun* - than writing tests after the fact.