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

Re: TDD - Planning Ahead

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.