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

Refactoring between test cases

Expand Messages
  • cwoodwar@csc.com
    Nick Fortescue posted a message on June 6th, 2001 about the XP2001 conference. In it he drew attention to Kent Beck and Alan Francis demonstration on test
    Message 1 of 64 , Jul 3, 2001
    • 0 Attachment
      Nick Fortescue posted a message on June 6th, 2001 about the XP2001
      conference. In it he drew attention to Kent Beck and Alan Francis
      demonstration on test first programming:

      "Kent Beck and Alan Francis (Object mentor) were demonstrating test first
      programming in the beginners introduction. They were writing code to turn
      integers into roman numerals. So they wrote the test for 1, coded 1, wrote
      the test for 2, coded 2, wrote the test for 3, coded 3, all the time
      refactoring so there was no duplication. Then they got to 4. Kent was
      driving. And they stopped. Eventually they did the test for 5
      next because it was simpler. Then they went back to 4. And got stalled
      again. They could both see easily how to do the big solution, but to see
      how to do the next small step was much harder. It is was a great revelation
      that even for two good programmers, programming in small steps wasn't easy.
      There is still a lot of skill to programming, even (especially?) the XP
      way."

      I was surprised by the use of refactoring to improve code just developed to
      satisfy the first test, in order to make it work for the second test, and
      so on. I didn't realise the process was so fastidious. Why, for example,
      with the knowledge (I assume) of the user story to convert integers into
      roman numerals wasn't it sensible (or permitted?) to at least anticipate
      from the start the requirement to code for values 1 to 5?

      Regards

      Chris W
      CSC Research Services
    • kentbeck@csi.com
      ... different in ... task, the ... I probably change my test cases 1/4 of the time, sometimes before changing the code, sometimes instead of changing the code.
      Message 64 of 64 , Jul 9, 2001
      • 0 Attachment
        --- In extremeprogramming@y..., wecaputo@t... wrote:
        > Bear in mind that the task (and its originating story) tells you the
        > problem to solve. As you point out Matthew, the problem is
        different in
        > each of your O(*) algorithims, thus for a real story, and a real
        task, the
        > requirements would need to be different to result in your different
        > algorithims.

        I probably change my test cases 1/4 of the time, sometimes before
        changing the code, sometimes instead of changing the code. Learning
        when to suspect your test case instead of your code is part of making
        the shift to a journeyman testfirster.

        Kent
      Your message has been successfully submitted and would be delivered to recipients shortly.