Share via

my opion on TDD...

  • Article

Around me, I'm seeing some people who are very deep into TDD.

Well, as QA, whenever I heard their mythical belief on TDD, It makes me think why TDD is believed that much.

TDD, it sounds like very testing oriented. yes it is. I agree. and it is good approach. but is it all? and can it find all issues? I don't think so. but many of TDD believers want to believe that it is the final solution for everything.

IMHO, I think that it is just a trend which is good trend because it is focusing on the quality of code at the beginning. however, I don't think that it is everything or final thing which can solve every problem or prevent all issues from your code.

Adding to TDD, we need to understand the bigger picture. you should see the forest with trees, too. otherwise,you will lose harmony in your overall design and process.

Comments

  • Anonymous
    July 18, 2004
    I'm a real TDD zealot, and the following things tend to come out when you talk to people starting out on it...
    1. They think it's solely about testing. It's not - the tests are a design tool as much (if not more) as they are actual tests.
    2. Lots of people that claim to do TDD actually don't - they write the code and the tests in parallel, which leads to less code coverage
    3. Lots of people that claim to do TDD give up when things seem really hard to test, so that only the illusion of robustness is there.

    I work for a bank on a team that's totally embraced TDD, and gone to the level of doing acceptance-test driven development, not just unit-test. The team has had defect-free deliveries into live (of major financial systems) for the last year or two.

    However, we believe the QA's role is one of the most important, working in two areas:
    1. Helping the Truth (business person) define the stories (requirements) and tests in such a way that they can be implemented programatically
    2. Working closely on the acceptance tests, as acceptance-testing frameworks for developers are still fairly immature

    To me, TDD should be put within it's business-value oriented context: does it make financial sense to do TDD? 95-99% of the time, yes. However, 1-5% of the time it's really expensive to implement automated tests - some things are inherently too complex to automate cost effectively. Over time, these figures will drop, but there will always be cases where some things can't be automated within TDD.
  • Anonymous
    July 19, 2004
    I understand your points about TDD, but they miss the point. As the previous poster said, TDD is not about testing, it is about design. It is also about giving the developer confidence when it comes time to make changes to the software.

    First of all, TDD is really about desiging your system from the point of view of the user. By writing one test before writing the code to make that test pass, you avoid the trap of writing a test to prove the code works. Instead, you are codifying the intent of that code before you've written the implementation of it.

    Second of all, once you have this network of tests around all of your code, you gain this tremendous sense of courage about making changes to that software. One of the biggest problems with changing existing software is the amount of testing that a developer should do to confirm that the change didn't break anything. By writing code using TDD, you get almost 100% test coverage, so you get a pretty good sense of confidence about whether or not a change worked. It's not perfect, but at least its pretty darn close.

    The piece that most QA folks I've trained in this stuff miss is the feedback part of the loop. Yes, it is possible to introduce defects while making changes to your system, even when practicing TDD to its fullest. But, part of the process is to look at those bugs and learn from them. You need to figure out why they slipped through your network of tests and learn to write better tests next time.

    QA is still an absolutely critical role on a team practicing TDD, but you're emphasis changes. You don't need to waste any (ok, much) time finding silly off-by-one errors, etc. You can focus your time on the really hard bugs, things that are hard to test in an automated fashion. You are more on the spot, as you can't pound out 10-15 bugs every day on silly things, but you get to be the savior when you find a really tough bug that only a real tester could have found.

    See my blog for more information and some war stories of TDD on a real team at Microsoft (stories coming over the next few weeks)
  • Anonymous
    July 19, 2004
    Min,

    In your words I recognize something - the same misunderstandings about TDD that I once had.

    I recorded my epiphany here:

    http://blogs.msdn.com/jaybaz_ms/archive/2004/06/02/146887.aspx

    I think it's an important read for anyone trying to understand TDD.