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

Re: [XP] TDD - Planning Ahead

Expand Messages
  • Dale Emery
    Hi Brandon, A quick off-topic question: what do you do about repetitive tests? Do you ... Yes, I factor common code into helper functions with expressive
    Message 1 of 22 , Dec 31, 2008
    • 0 Attachment
      Hi Brandon,

      A quick off-topic question: what do you do about repetitive tests? Do you
      > refactor them, too? I find that many tests end up being repetitive.


      Yes, I factor common code into helper functions with expressive names, so
      that each test reads more concisely and meaningfully. Sometimes I notice
      patterns about which tests use which helper functions, and that can nudge me
      to split or combine fixtures.

      My goal: Make the tests readable, understandable, and changeable. For some
      reason I tend to go less far in refactoring tests than I do in refactoring
      the working code, but I do put a good deal of attention to making my tests
      clean and readable.

      Dale

      --
      Dale Emery, Consultant
      Inspiring Leadership for Software People
      Web: http://dhemery.com
      Weblog: http://cwd.dhemery.com


      [Non-text portions of this message have been removed]
    • Ron Jeffries
      Hello, Brandon. On Wednesday, December 31, 2008, at 6:36:29 AM, ... I think all the time. I code only what I need right now, in some simple and clear way. Ron
      Message 2 of 22 , Jan 1, 2009
      • 0 Attachment
        Hello, Brandon. On Wednesday, December 31, 2008, at 6:36:29 AM,
        you wrote:

        > I'm writing a class now that I'm really not sure how I'm going to implement
        > certain parts. Of course, I'm writing each test before implementing it.
        > I've read before about not thinking too far in the future, and only writing
        > the code that makes the test pass. How literally do you take this? Is it
        > wise to try to look in the future to find the best implementation of the
        > class, or literally only write as much as is needed to make the test pass
        > right now, even if it will be changed later?

        I think all the time. I code only what I need right now, in some
        simple and clear way.

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        The rules are ways of thinking, not ways to avoid thinking.
      • Arnaud Bailly
        Hello, One thing I found useful is to establish some sort of plan through a list of tests that I order and implement one at a time. Like all plans, it should
        Message 3 of 22 , Jan 1, 2009
        • 0 Attachment
          Hello,
          One thing I found useful is to establish some sort of plan through a
          list of tests that I order and implement one at a time. Like all plans,
          it should be following you, not followed by the letter: changing the
          order, removing unnecessary or duplicate tests, adding some more
          tests...

          And yes, you have to think all the time, because design and code is
          one and the same thing.

          Regards,
          --
          Arnaud Bailly, PhD
          OQube - Software Engineering

          web> http://www.oqube.com
        • Phlip
          ... Right: Then you can sort the list and do the items from easy to hard. Subsequent tests can reuse fixtures invented for the simpler tests. The goal is each
          Message 4 of 22 , Jan 1, 2009
          • 0 Attachment
            Arnaud Bailly wrote:

            > One thing I found useful is to establish some sort of plan through a
            > list of tests that I order and implement one at a time. Like all plans,
            > it should be following you, not followed by the letter: changing the
            > order, removing unnecessary or duplicate tests, adding some more
            > tests...

            Right: Then you can sort the list and do the items from easy to hard. Subsequent
            tests can reuse fixtures invented for the simpler tests.

            The goal is each test failure tells you the next valuable thing to do to the
            code, in the right order. So even within one test case you can write a missing
            method, then write a few assertions, listed in the order you ought to pass them
            as you build that method.

            --
            Phlip
          • Keith Ray
            If the tests have a lot of duplication testing an aspect of a class, that can mean that you should extract a class to represent that aspect. Now you have two
            Message 5 of 22 , Jan 1, 2009
            • 0 Attachment
              If the tests have a lot of duplication testing an aspect of a class,
              that can mean that you should extract a class to represent that
              aspect. Now you have two classes and I would move some of the tests to
              a test suite for that new class and remove duplication in them.

              Sent from my iPhone

              On Dec 31, 2008, at 1:34 PM, "Brandon Olivares" <programmer2188@...
              > wrote:

              > Hi,
              >
              > Thanks so much. This all really helps.
              >
              > It is difficult, but I am really liking it so far. I don't know yet
              > how this
              > class will end up implementing the needed functionality, though. I
              > just know
              > how it passes the tests so far. Quite interesting.
              >
              > A quick off-topic question: what do you do about repetitive tests?
              > Do you
              > refactor them, too? I find that many tests end up being repetitive.
              >
              > Thanks,
              > Brandon
              >
              >> -----Original Message-----
              >> From: extremeprogramming@yahoogroups.com
              >> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Adam Sroka
              >> Sent: Wednesday, December 31, 2008 4:08 PM
              >> To: extremeprogramming@yahoogroups.com
              >> Subject: Re: [XP] TDD - Planning Ahead
              >>
              >> On Wed, Dec 31, 2008 at 12:07 PM, Dale Emery <dale@...
              >> <mailto:dale%40dhemery.com> > wrote:
              >>> Hi Brandon,
              >>>
              >>> Technically, you could go on faking it indefinitely, but you know
              >>> you
              >> mean
              >>>> to actually do something else with it. For instance if I have a
              >> method
              >>>> that
              >>>> needs to return a count of something, I could return the expected
              >> number,
              >>>> but I know I really want the count, no matter what it is.
              >>>
              >>> That's what makes the "refactor" step so important. As you write the
              >> code
              >>> to pass your second or third or fourth test, you will likely
              >> introduce some
              >>> repetition or pattern or awkwardness into the code. Once the code
              >> passes
              >>> the tests, you'll notice that smell and refactor the code to be
              >> simpler.
              >>>
              >>> One trick I've learned is how to select the next test: Select one
              >> that
              >>> nudges the existing code toward a /little/ more ugliness. Then
              >> refactor the
              >>> ugliness out. With counts, I find that tests for zero, one, and many
              >> items
              >>> usually is enough to force just the right amount of ugliness, which
              >> in turn
              >>> forces the code toward its final form (loop, internally-stored
              >>> count,
              >>> regular expression). That's three tests, which you can write and
              >>> pass
              >>> within a few minutes.
              >>>
              >>
              >> Ditto all of the above.
              >>
              >> You have to know when you are close enough to the "real" answer that
              >> you can get there with one small step. That is the trick. It is true
              >> that you could go on faking it for a long time. But, as you said the
              >> goal is to get to the "real" thing. You just want to lower the
              >> resistance enough that you can get there with a small, logical,
              >> easily
              >> tested change. These are the "baby steps" that Kent Beck talks about.
              >>
              >> BTW, a similar method has been described as "triangulation". I'm not
              >> sure where the term originates, but Dave Astels used it in his book.
              >> Basically, you write two tests that expect two different values from
              >> the same code. When you write the second implementation to return the
              >> second value you will have created duplication which you can refactor
              >> out.
              >>
              >> Another trick is to look for a value that wouldn't naturally come out
              >> of the code and test for that in order to force yourself to get the
              >> "real" value. This is the approach that I prefer when using mocks.
              >> For
              >> example, if my initial test checks for zero (or null, nil, undef,
              >> whatever your language returns by default) then I might mock
              >> something
              >> to produce the value "5" and expect that answer in my test. Then I
              >> can
              >> set my implementation to get it from the right place. You could argue
              >> that it is simpler to just return the hardcoded value, but this is a
              >> small enough step that I am comfortable.
              >>
              >>
              >>
              >
              >
              > ------------------------------------
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.comYahoo! Groups Links
              >
              >
              >
            • Brandon Olivares
              ... Can you explain a bit what you mean? I don t know if I see your point there. To me, testing has a lot of duplication. I mean you are testing all of the
              Message 6 of 22 , Jan 1, 2009
              • 0 Attachment
                > -----Original Message-----
                > From: extremeprogramming@yahoogroups.com
                > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                > Sent: Thursday, January 01, 2009 2:02 PM
                > To: extremeprogramming@yahoogroups.com
                > Cc: <extremeprogramming@yahoogroups.com>
                > Subject: Re: [XP] TDD - Planning Ahead
                >
                > If the tests have a lot of duplication testing an aspect of a class,
                > that can mean that you should extract a class to represent that
                > aspect. Now you have two classes and I would move some of the tests to
                > a test suite for that new class and remove duplication in them.
                >

                Can you explain a bit what you mean? I don't know if I see your point there.
                To me, testing has a lot of duplication. I mean you are testing all of the
                fringe cases of a method, so you'll be calling each one quite a few times.

                Thanks,
                Brandon

                Brandon
              • Keith Ray
                I have an example of a large method in my article here: Pretend the large method in
                Message 7 of 22 , Jan 2, 2009
                • 0 Attachment
                  I have an example of a large method in my article here:
                  <http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=75>

                  Pretend the large method in Figure 1 was created by TDD with
                  insufficient refactoring. There would be a large number of tests for
                  that method, reflecting the large amount of behavior in that method.
                  The article describes several extract methods that can be done. And
                  points out some Move Method refactorings to correct a Feature Envy
                  code smell -- moving some methods out of the nsAccessibleText class
                  into the class nsISelectionController.

                  If you were test-driving nsAccessibleText, and now fixing code smells,
                  you might have created the class nsISelectionController just to move
                  the methods into it. I would move some of those tests that drove the
                  creation of the code that we did Move Method on into a test-suite for
                  nsISelectionController.

                  As the article continues, we observe that BackupOldSettings and
                  RestoreOldSettings are being used to save and restore some data
                  belonging to the class nsISelectionController, but the class doing
                  this work is nsAccessibleText. This is an Inappropriate Intimacy code
                  smell, and one way to fix it is to use the Memento design pattern.
                  Again we have created a new class [possibly an "inner class"], and we
                  can maybe move some tests from the original class test-suite to
                  another one.

                  And we observe that several methods have two parameters that always go
                  together - aStartOffsetand and aEndOffset. Data Clump code smell. Move
                  those into a new "Range" class and extract and move methods like
                  "Length" into that class and again there could be an opportunity to
                  not only remove duplication in the code, but also in tests that may
                  have been testing that several methods computed length or other
                  functionality that belongs in Range.

                  The examples from this article came from un-tdd'ed legacy code with
                  very few unit tests, but I have seen people new to TDD ignore the same
                  code smells when test-driving a class. The code-smells were not just
                  in the production code, but also in the extreme duplication of the
                  test code, and the fixes were to remove duplication in both the
                  production code (by extracting methods and classes) and the tests.

                  Jay Flowers wrote a blog entry about TDD smells here
                  <http://jayflowers.com/WordPress/?p=89>
                  "Looking at this now I think I went to great lengths to make the
                  test look simple, to cover up the complexity [...]"
                  "So what grabs you by the nose and leads to tight coupling? I
                  don't know yet. Maybe looking at motivations will help. I was
                  motivated to perform this refactoring because [...] I think we can
                  pull these smells out:
                  * Slow Tests
                  * Lengthy SetUp
                  * Lengthy TearDown
                  * Asynchronous Test
                  * Party Crasher
                  "Two of those smells have already been identified by Gerard and are
                  documented in xUnit Patterns."

                  On Thu, Jan 1, 2009 at 12:27 PM, Brandon Olivares
                  <programmer2188@...> wrote:
                  >
                  >
                  >> -----Original Message-----
                  >> From: extremeprogramming@yahoogroups.com
                  >> [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                  >> Sent: Thursday, January 01, 2009 2:02 PM
                  >> To: extremeprogramming@yahoogroups.com
                  >> Cc: <extremeprogramming@yahoogroups.com>
                  >> Subject: Re: [XP] TDD - Planning Ahead
                  >>
                  >> If the tests have a lot of duplication testing an aspect of a class,
                  >> that can mean that you should extract a class to represent that
                  >> aspect. Now you have two classes and I would move some of the tests to
                  >> a test suite for that new class and remove duplication in them.
                  >>
                  >
                  > Can you explain a bit what you mean? I don't know if I see your point there.
                  > To me, testing has a lot of duplication. I mean you are testing all of the
                  > fringe cases of a method, so you'll be calling each one quite a few times.
                  >
                  > Thanks,
                  > Brandon
                  >
                  > Brandon
                  >
                  >
                  > ------------------------------------
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.comYahoo! Groups Links
                  >
                  >
                  >
                  >



                  --
                  C. Keith Ray, IXP Coach, Industrial Logic, Inc.
                  http://industriallogic.com 866-540-8336 (toll free)
                  Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
                  http://agilesolutionspace.blogspot.com/
                • Brandon Olivares
                  Keith, Thanks a lot for the links. The class I was having trouble with is just about finished, and the design is completely different than I had originally
                  Message 8 of 22 , Jan 2, 2009
                  • 0 Attachment
                    Keith,

                    Thanks a lot for the links.

                    The class I was having trouble with is just about finished, and the design is completely different than I had originally planned, before I decided to try this approach. This design that has come out of it though is much simpler and cleaner than what I was thinking of. It's definitely something to get used to, but I like it.

                    Brandon

                    > -----Original Message-----
                    > From: extremeprogramming@yahoogroups.com
                    > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                    > Sent: Friday, January 02, 2009 11:27 AM
                    > To: extremeprogramming@yahoogroups.com
                    > Subject: Re: [XP] TDD - Planning Ahead
                    >
                    > I have an example of a large method in my article here:
                    > <http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=75
                    > <http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=75>
                    > >
                    >
                    > Pretend the large method in Figure 1 was created by TDD with
                    > insufficient refactoring. There would be a large number of tests for
                    > that method, reflecting the large amount of behavior in that method.
                    > The article describes several extract methods that can be done. And
                    > points out some Move Method refactorings to correct a Feature Envy
                    > code smell -- moving some methods out of the nsAccessibleText class
                    > into the class nsISelectionController.
                    >
                    > If you were test-driving nsAccessibleText, and now fixing code smells,
                    > you might have created the class nsISelectionController just to move
                    > the methods into it. I would move some of those tests that drove the
                    > creation of the code that we did Move Method on into a test-suite for
                    > nsISelectionController.
                    >
                    > As the article continues, we observe that BackupOldSettings and
                    > RestoreOldSettings are being used to save and restore some data
                    > belonging to the class nsISelectionController, but the class doing
                    > this work is nsAccessibleText. This is an Inappropriate Intimacy code
                    > smell, and one way to fix it is to use the Memento design pattern.
                    > Again we have created a new class [possibly an "inner class"], and we
                    > can maybe move some tests from the original class test-suite to
                    > another one.
                    >
                    > And we observe that several methods have two parameters that always go
                    > together - aStartOffsetand and aEndOffset. Data Clump code smell. Move
                    > those into a new "Range" class and extract and move methods like
                    > "Length" into that class and again there could be an opportunity to
                    > not only remove duplication in the code, but also in tests that may
                    > have been testing that several methods computed length or other
                    > functionality that belongs in Range.
                    >
                    > The examples from this article came from un-tdd'ed legacy code with
                    > very few unit tests, but I have seen people new to TDD ignore the same
                    > code smells when test-driving a class. The code-smells were not just
                    > in the production code, but also in the extreme duplication of the
                    > test code, and the fixes were to remove duplication in both the
                    > production code (by extracting methods and classes) and the tests.
                    >
                    > Jay Flowers wrote a blog entry about TDD smells here
                    > <http://jayflowers.com/WordPress/?p=89
                    > <http://jayflowers.com/WordPress/?p=89> >
                    > "Looking at this now I think I went to great lengths to make the
                    > test look simple, to cover up the complexity [...]"
                    > "So what grabs you by the nose and leads to tight coupling? I
                    > don't know yet. Maybe looking at motivations will help. I was
                    > motivated to perform this refactoring because [...] I think we can
                    > pull these smells out:
                    > * Slow Tests
                    > * Lengthy SetUp
                    > * Lengthy TearDown
                    > * Asynchronous Test
                    > * Party Crasher
                    > "Two of those smells have already been identified by Gerard and are
                    > documented in xUnit Patterns."
                    >
                    > On Thu, Jan 1, 2009 at 12:27 PM, Brandon Olivares
                    > <programmer2188@... <mailto:programmer2188%40gmail.com> > wrote:
                    > >
                    > >
                    > >> -----Original Message-----
                    > >> From: extremeprogramming@yahoogroups.com
                    > <mailto:extremeprogramming%40yahoogroups.com>
                    > >> [mailto:extremeprogramming@yahoogroups.com
                    > <mailto:extremeprogramming%40yahoogroups.com> ] On Behalf Of Keith Ray
                    > >> Sent: Thursday, January 01, 2009 2:02 PM
                    > >> To: extremeprogramming@yahoogroups.com
                    > <mailto:extremeprogramming%40yahoogroups.com>
                    > >> Cc: <extremeprogramming@yahoogroups.com
                    > <mailto:extremeprogramming%40yahoogroups.com> >
                    > >> Subject: Re: [XP] TDD - Planning Ahead
                    > >>
                    > >> If the tests have a lot of duplication testing an aspect of a class,
                    > >> that can mean that you should extract a class to represent that
                    > >> aspect. Now you have two classes and I would move some of the tests
                    > to
                    > >> a test suite for that new class and remove duplication in them.
                    > >>
                    > >
                    > > Can you explain a bit what you mean? I don't know if I see your point
                    > there.
                    > > To me, testing has a lot of duplication. I mean you are testing all
                    > of the
                    > > fringe cases of a method, so you'll be calling each one quite a few
                    > times.
                    > >
                    > > Thanks,
                    > > Brandon
                    > >
                    > > Brandon
                    > >
                    > >
                    > > ------------------------------------
                    > >
                    > > To Post a message, send it to: extremeprogramming@...
                    > <mailto:extremeprogramming%40eGroups.com>
                    > >
                    > > To Unsubscribe, send a blank message to: extremeprogramming-
                    > unsubscribe@... <mailto:extremeprogramming-
                    > unsubscribe%40eGroups.com>
                    > >
                    > > ad-free courtesy of objectmentor.comYahoo! Groups Links
                    > >
                    > >
                    > >
                    > >
                    >
                    > --
                    > C. Keith Ray, IXP Coach, Industrial Logic, Inc.
                    > http://industriallogic.com <http://industriallogic.com> 866-540-8336
                    > (toll free)
                    > Groove with our Agile Greatest Hits:
                    > http://www.industriallogic.com/elearning/
                    > <http://www.industriallogic.com/elearning/>
                    > http://agilesolutionspace.blogspot.com/
                    > <http://agilesolutionspace.blogspot.com/>
                    >
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.