Is Testing The Ultimate Goal?

Whenever you throw TDD without worshiping it you turn yourself immediately in a victim of religious fundamentalists. TDD is a gift from god, it's good, it's cool and should never be questioned. It's a dogma.

Frans Bouma complains about it and the lack of scientific proof of the fact that TDD is really useful and good. Phil Haack throws a paper at him (which I haven't read - just looked at) but, from his own comments, doesn't dismiss Frans's point.

Why are we testing code anyway? What does it prove? According to Frans, not much. I'll have to agree with Frans on this. In summary, first you need to prove (or have proof) that what you are going to code is the right thing. Only then you can prove that you've done it correctly.

This goes even further when frameworks like TypeMock are considered too powerful. They are seen as evil in the eyes of the purists. Roy Osherove questions his readers and TypeMock community about this.

While we have to have in mind Frans' post about correctness provability, Travis does make a good point when he questions "Design for testability vs. API as a deliverable".

My bottom line in this subject is that testing tools are just tools like any other tools use in software development. The fact that they are becoming so good and powerful just changes what tools we use and how we use them.

I like compiled languages because they give me confidence over interpreted languages, because I can assert that although my code might have some errors on what it does it doesn't have any errors on how it was written.

On another level, unit testing and mock frameworks give me confidence that my code will do exactly what I intended it to do. Which might still not be correct.

2 Responses to Is Testing The Ultimate Goal?

  • Nis L. Simonsen says:

    Well, Frans point was, as I see it, that testing can never substiture proof that some code is correct.

    He writes “automated tests can show you you broke something which did work before. So they can prove your code ISN’T correct. They can’t prove your code IS correct. That’s a big difference and often overlooked.”

    Indeed, that is a fundamental issue of TDD that some people overlook, but that experienced developers should understand.
    To that effect, I think Phil Haacks point is relevant, namely that approaching from a tdd pov seems to generate a larger number of relevant tests, which in turn means that your algorithm is more likely to be correct. (Not Correct with a capital C though).
    There is a famous Knuth quote along the lines of “Beware of bugs in the above code. I have only proven it correct, not tested it” that goes to illustrate the initial point.

  • But, does the above mentioned paper, as it is and on its own, account for scientific proof?