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

Re: [XP] [conclusion] Unit Testing Question [ some explanations & a better example]

Expand Messages
  • Dale Emery
    Hi Greg, ... Exactly. So your worry was justified, and was telling you something important about your tests. ... That s right. In this case, I think the
    Message 1 of 6 , Aug 22, 2007
      Hi Greg,

      > I was worried that my test of the function I described
      > were
      > insufficient to capture the change my refactoring created,
      > and they
      > were insufficient

      Exactly. So your worry was justified, and was telling you
      something important about your tests.

      > as many of you pointed out, since the client
      > of that method has changed, there should have been test
      > written higher
      > up that would drive each of the scenarios hence the
      > mistake would have
      > been uncovered.

      That's right. In this case, I think the right "body of
      code" for those tests is the collaboration we talked about
      earlier. That collaboration--the combination of the
      factory and the readers--has the responsibility to return a
      reader that can read a given file.

      That's what I wanted to say now that we have the "what body
      of code are we refactoring" question sorted out. Once we
      know what body of code we're refactoring, then I know where
      I want the tests: I want the body of code that I'm
      refactoring (the body that satisfies the three conditions I
      gave earlier) to have enough tests to tell me whether I've
      changed its behavior.

      The collaboration of factory and readers has at least these
      responsibilities:
      1. Create and return a reader that can read xWhatever files
      with US dates.
      2. Create and return a reader that can read xWhatever files
      with EU dates.

      Before the change, the collaboration satisfied both of those
      responsibilities. After the change, it did not. And your
      tests didn't tell you that, which means that you were
      missing tests for one or more of those responsibilities.

      In general, when I'm refactoring, I want to have tests that
      are sufficiently close to the body of code I'm refactoring.
      If I'm refactoring a method, I might have direct tests for
      that method. That's as close as I can get. But sometimes I
      can live without tests for the method if /all of the
      method's clients/ have tests. That's one level of
      indirection away from the method I'm refactoring. If my
      tests are further away than that--if the nearests tests for
      for the callers of the callers of the code I'm changing--I
      start to get nervous.

      I certainly don't want to rely on system tests to detect
      problems in my refactorings. System tests are too far away
      from the code I'm fiddling with. I want tests much closer
      to the "body of code" that I'm refactoring.

      In your case, the GetReader() method doesn't have direct
      tests. I'd feel safer refactoring in that case if all of
      GetReader()'s callers have tests for all of their
      responsibilities. If I'm feeling unsafe, there's a good
      chance that one or more of GetReader()'s direct callers has
      important responsibilities that I'm not yet testing.

      > My situation is different, I do not work on system like
      > that. I also
      > find the argument that even if a system does not have
      > test, such test
      > should be written when a piece of the code is being
      > refactored, a
      > compelling argument. I fear that it may be impossible to
      > write such
      > test sometime but I will take it as it comes.

      Michael Feathers's book Working Effectively with Legacy Code
      is absolutely brilliant, and can help you to get untested
      code under test in a safe, stepwise way. I highly recommend
      it to you (and sometimes to random strangers on airplanes
      and in bank queues).

      Dale

      --
      Dale Emery, Consultant
      Inspiring Leadership for Software People
      Web: http://www.dhemery.com
      Weblog: http://www.dhemery.com/cwd
    Your message has been successfully submitted and would be delivered to recipients shortly.