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

92707RE: Why preserve TDD tests anyway (was RE: [XP] Testing Leftover)

Expand Messages
  • Lior Fridman
    Jun 1, 2004
    • 0 Attachment
      I want to focus on the point several people have made about the ability
      to test all the classes by using only public interfaces.

      I agree!

      If the behavior of all the interfaces is correct than I do not care what
      the class does inside.
      However if I go back to my case it all started out as you said
      I wrote down the tests I thought needed to test the class behavior (via
      using the interfaces only)
      And than I started coding. At some point ive got all the tests working
      and I said "ok now lets
      make the code cleaner" I don't want to use the refacturing term cause I
      don't really think I truly used any refacturing mechanisms,
      but the intention was the same.

      So after doing this for a while ive got to the point when one of my
      tests broke
      The reason was that I made a stupid mistake in changing the registration
      method a mistake that was only caught later on by a test to the
      monitoring part.

      Now it took me a while to find this out so I wanted to make sure that
      this wont happen again
      And here is were this thread came into being. I didn't have a way to
      check it.

      So ive added a function that searched the list of the registered
      components to check if after I register a component it is there.
      Now I needed to place this function. So ok it's a basic getter/finder
      function lets add it to the class.
      But wait no one outside the testing actually need it so I don't want to
      add a chunk of unused code into the class so lets put it in the test
      class and make the test class a friend, It actually stayed this way for
      a couple of weeks until I wanted to publicate the whole thing and I
      noticed I just did something very bad. Left testing code in the
      operational code.
      And this is the story of this thread.

      The morale of all this is (I think)
      1) yes I caught the problem by only testing interfaces.
      2) I still want the ability to test private methods/access private
      members.
      3) this ability will help me fix the problem faster (and not find
      problem that were not found by the interfaces tests)

      Lior


      Lior



      -----Original Message-----
      From: Michael Feathers [mailto:mfeathers@...]
      Sent: Monday, May 31, 2004 9:33 PM
      To: Steven Gordon
      Subject: Re: Why preserve TDD tests anyway (was RE: [XP] Testing
      Leftover)

      SG> I believe the underlying point of this thread is the question "Why
      SG> should we bother preserving the unit tests we develop under TDD
      SG> anyway?". After all, if anything breaks in the system, one or more
      acceptance tests should break, so why not just throw the unit tests away
      after they have guided our design and proved that our code works as we
      designed it to work!

      SG> We SHOULD preserve the unit tests we develop under TDD because of 2
      basic reasons:
      SG> 1. When refactoring later, the more granular our regression test
      SG> suite, the easier it is to identify the place where the
      code broke.
      SG> 2. To document our design in a way that can be verified by simply
      executing the documentation.

      Agreed.

      SG> Disposing of our unit tests after design is to lose valuable
      information. This is true of the unit tests of methods that were later
      made private, as well as the unit tests of public methods.

      Agreed, except there is no time called "after design."

      SG> In Java, reflection would be the cleanest approach to preserving
      SG> unit tests for private methods without warping your production code.

      SG> In C++, I would consider using an IFDEF around the "private:" in the
      .h files of the production classes. You could also break unit test
      cases for classes into one for the public methods and one for the
      private methods and use the same IFDEF to include/disclude those test
      cases from your CppUnit test suites.

      I agree except that.. the fact that we want to test a private method is
      giving us valuable design information too. The test is telling us that
      the method should be public. If not on this class, then on another.

      Classes that can not be tested through their public interface are not
      designed well. We can always design classes in a way that makes them
      directly testable.

      Michael Feathers
      www.objectmentor.com



      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links








      The information contained in this message is proprietary of Amdocs,
      protected from disclosure, and may be privileged.
      The information is intended to be conveyed only to the designated recipient(s)
      of the message. If the reader of this message is not the intended recipient,
      you are hereby notified that any dissemination, use, distribution or copying of
      this communication is strictly prohibited and may be unlawful.
      If you have received this communication in error, please notify us immediately
      by replying to the message and deleting it from your computer.
      Thank you.
    • Show all 12 messages in this topic