Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Testing increasing time significantly?

Expand Messages
  • Steve Freeman
    As someone has already pointed out, it ll take you a while to really get fluent in TDD, so you re comparing your existing experience against a new skill. In
    Message 1 of 61 , Dec 31, 2008
    • 0 Attachment
      As someone has already pointed out, it'll take you a while to really
      get fluent in TDD, so you're comparing your existing experience
      against a new skill.

      In the meantime, here's a recent study from Microsoft

      http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf

      "Case studies were conducted with three development teams at Microsoft
      and one at IBM that have adopted TDD. The results of the case studies
      indicate that the pre-release defect density of the four products
      decreased between 40% and 90% relative to similar projects that did
      not use the TDD practice. Subjectively, the teams experienced a 15-35%
      increase in initial development time after adopting TDD."

      S.


      On 24 Dec 2008, at 19:29, Brandon Olivares wrote:
      > Hi,
      >
      > So I decided to put an honest effort into trying TDD.
      >
      > My feeling about it after trying it on a single user story is that
      > it's
      > really, really useful, and gives a lot of assurance, but is a pain
      > to write,
      > and increases the time to program significantly. I estimate it
      > increased the
      > time it took me to program this threefold, from what it would have
      > been had
      > I not used tests. I had 54 unit tests and 92 functional tests, so it
      > definitely was a lot to write.
      >
      > So my question is, is the benefit gained from doing this, enough to
      > offset
      > the extra time? I'm really happy with it, because after I wrote
      > those tests,
      > I was fairly confident I could test it out through the UI myself
      > without any
      > difficulties, and indeed I could. I'm fairly confident there aren't
      > any
      > major hidden bugs, unless I missed a very fringe case.
      >
      > But, it took a long time.
      >
      > Thoughts?
      >
      > Thanks,
      > Brandon
      >

      Steve Freeman
      http://www.mockobjects.com

      Winner of the Agile Alliance Gordon Pask award 2006
    • J. B. Rainsberger
      ... I m late to the party, so this might be old news by now. Don t compare apples to oranges. When you consider the cost of delivering that story without doing
      Message 61 of 61 , Jan 15, 2009
      • 0 Attachment
        On 2008-12-24, at 19:29 , Brandon Olivares wrote:
        > So I decided to put an honest effort into trying TDD.
        >
        > My feeling about it after trying it on a single user story is that
        > it's
        > really, really useful, and gives a lot of assurance, but is a pain
        > to write,
        > and increases the time to program significantly. I estimate it
        > increased the
        > time it took me to program this threefold, from what it would have
        > been had
        > I not used tests. I had 54 unit tests and 92 functional tests, so it
        > definitely was a lot to write.
        >
        I'm late to the party, so this might be old news by now.

        Don't compare apples to oranges. When you consider the cost of
        delivering that story without doing TDD, including the cost to program
        it, the cost to fix all the defects you and your testing organization
        find, the cost to plan and decide which defects to fix and which
        defects to risk delivering to your customer, the cost to argue with
        your testers about whether something is a defect or not, and the cost
        to go back and rewrite 40% of that code in three months when you try
        to add a feature that touches your design and you learn that your old
        design is too rigid to accommodate the new feature.

        If you add up all those costs, you might find a vastly different
        comparison.

        Also, as with any technique, with practice comes speed.
        ----
        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
        Your guide to software craftsmanship
        JUnit Recipes: Practical Methods for Programmer Testing
        2005 Gordon Pask Award for contributions to Agile Software Practice
      Your message has been successfully submitted and would be delivered to recipients shortly.