Pros and Cons of Test driven development

    General discussion



    I am tryign to compile a list of pros and cons for TDD, so far i have come up with the following, any comments, additions would be highly appreciated


    1 - Tested code is written and test automation is easily achievable from the beginning of the project
    2 - Easier to leave your code and come back later - assuming you got the test in place
    3 - Sample code available to others
    4 - Red-Green-Refractor implies less time spent on debugging
    5 - Developers can see the effect of design decisions within minutes, instead waiting for the regressing cycle
    6 - Gives management many tools, including predictability, flexibility of resources, consistency, and visibility into what's really going on
    7 - Conflicting requirements detected easily
    8 - Breaking changes in business rules are detected without regression, hence code can be modified without fear of breaking existing changes
    9 - If used in conjunction with a tracebility matrix, can give a very accurate state of the project
    10- writing acceptance tests first makes developers think more about value before starting to code


    1 - Religious refactoring is essential
    2 - Tests can't be tested! so review is essential for the tests
    3 - a new way to think about problem would be met with resistance
    4 - a large project may include a lot of tests that take considerable time to execute -  build servers can be a solution
    5 - when modifying any business logic, the related test cases have to be maintained accordingly this may become a big overhead if the changes are more frequent
    6 - test writing skills develop over time
    7 - desigining test cases in a multi-threaded envoirnment is very difficult.


    Sunday, January 20, 2008 10:58 PM

All replies

  • BigW,
        I would highly recommend you read "Some Assembly Required" p.62 -68 in the latest edition of Better Software Magazine. It does not denigrate Test Driven Development, but lays out several landmines of TDD that can prevent quality software. Jennitta Andrea makes the point that you must "read the fine print" to make TDD a success.

       She says at one point "It doesn't have to be this way. TDD actually does work. It just takes a tremendous amount of discipline and an understanding of where the 'landmines' are.

       Some of the "landmines" that I've heard about TDD include
    1. Tests as requirement specification tends to focus on the process rather than the user and usability.
    2. Code is written "as simply as possible in order to pass the tests", not to improve overall quality or to accomodate future, even planned, enhancement.
    3. TDD tends to de-emphasize exploratory and usability testing (often without experienced testers ever examining the program); you  should probably still employ some exploratory, stress, load, performance, usability testing, etc. after it passes the automated tests.
    4. TDD uses some misnomers like "acceptance test" that leads development to assume that the code is implicity accepted by the user when the automated tests pass, but they often fail with "live data" from the customer.
    5. TDD is not always appropriate, especially for "quick and dirty prototyping", etc.

       If you are going down that path, obtain the magazine or the article online if you have a membership to the content. You might also want to read Test-Driven Design isn't Testing.

    Hope this helps,
    Monday, January 21, 2008 2:26 AM