Sponsored Link •
My recent blog-post "Post-TDD" has generated some interesting and lively discussion. Here are some more of my thoughts and clarifications.
There have been a lot of insightful and education comments (at least for me) so far on the weblogs forum in response to my blog post Post-TDD for which I am very appreciative. One of my points though I think didn't come across.
My thesis: given two design which accomplish the same thing, the one which requires fewer tests is a better design. This I believe to be true from either a Quality Assurance (QA) point of view, or a TDD point of view. This is why I say that we want to somehow strive towards elimination of tests in our designs. When it is possible to forecast the number of tests required for a design decision, in theory it should make it easier to make design choices. Perhaps this could lead to software which makes design decisions, though this is probably pretty far out there.
My previous conflation of TDD and QA was somewhat intentional, because I think that QA is automatically a goal of any programmer, and any methodology. I assert that the biggest advantage of TDD by itself is QA through incidental correctness testing.
A development methodology in of itself is useless, unless it helps us achieve our goal as programmers:
Writing correct software in the shortest amount of time.
|Christopher Diggins is a software developer and freelance writer. Christopher loves programming, but is eternally frustrated by the shortcomings of modern programming languages. As would any reasonable person in his shoes, he decided to quit his day job to write his own ( www.heron-language.com ). Christopher is the co-author of the C++ Cookbook from O'Reilly. Christopher can be reached through his home page at www.cdiggins.com.|