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

RE: [scrumdevelopment] Balance between writing unit tests and shipping code

Expand Messages
  • Wolfgang Schulze Zachau
    (replying to Keith and John) considering that in all but the most trivial cases you will need at least 2 unit tests per method (and in some cases up to several
    Message 1 of 8 , Feb 1, 2007
      (replying to Keith and John)
       
      considering that in all but the most trivial cases you will need at least 2 unit tests per method (and in some cases up to several dozen to cover all possible combinations of inputs and all possible results), it would be realistic to say that the size of test code will always dwarf the size of the application code (particularly after serious refactoring). In consequence there is nothing wrong with spending lots of time on the test code. As others have pointed out, if your tests have good coverage and fine granularity, developers will reduce spending time in the debugger considerably. In return you will get  high quality code.
       
      In fact, the quality of the code will follow exactly the quality of the requirements provided by the product owner. The more precisely and comprehensively the PO can state his acceptance criteria, the more better your test coverage will be and in consequence the better the code will match the business requirements.
       
      I suggest you and the team try TDD with a relatively simple (yet real !!) part of the project. Follow the book by the letter and see the results. It is truly amazing, but be prepared to change paradigms on the way.
       

      Regards,

      Wolfgang

    • Andy
      ... Took the words right out of my mouth. You don t introduce new functionality, or fix broken functionality, unless there s a test to cover the issue you re
      Message 2 of 8 , Feb 1, 2007
        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
        <ronjeffries@...> wrote:
        >
        > It's not about hours. It's about enough.
        >

        Took the words right out of my mouth. You don't introduce new
        functionality, or fix broken functionality, unless there's a test to
        cover the issue you're trying to address.

        If you haven't written that test, you haven't spent enough time on it.

        This assumes you're doing TDD or BDD of course. After 15 months of
        doing it, I can't imagine coding any other way. Coding anything other
        than spike solutions without TDD has become almost unthinkable.

        Andy.
      • Anoshlal Sulgaonkar
        We write the acceptance test using a testing tool known as STIQ (Story test IQ). We consider writing tests as a part of coading. We write the tests first and
        Message 3 of 8 , Feb 1, 2007
          We write the acceptance test using a testing tool known as STIQ (Story test IQ). We consider writing tests as a part of coading. We write the tests first and then code to pass the tests. This makes our lives easy.


          Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
        Your message has been successfully submitted and would be delivered to recipients shortly.