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

9198Re: [XP] Testing experiences

Expand Messages
  • Michael D. Hill
    Aug 1, 2000
      Johannes and Kevin...

      Nice posts, and I need to throw off some sparks from them.

      At 07:59 PM 7/31/00 -0700, Kevin wrote:
      >>Welcome, and thanks for asking a"real" xp question to distract us
      >>away from Einstein and machine parts.

      Ditto, believe me. Sometimes this place is noisier than Wiki.

      Johannes sez:
      >I have installed *Unit on my system, and started using it. It seems to be
      >quite difficult to make usable tests for my programs, though. I have run
      >into a lot of minor and major hurdles when I have tried implementing unit
      >tests: I feel that my code is too tightly coupled, so I guess breaking it
      >apart is a useful practice with or without the testing. I also I have no
      >idea about how many tests I should have, their granularity, and how paranoid
      >I should be in my testing.

      Kevin replies:
      >>How many tests? I think I have heard a rule of thumb that each non-trivial
      >>public function (method) should have a test. The tests should aim for
      >>complete coverage of all the code paths of both the public function and each
      >>private function. For each class I create, I tend to create a corresponding
      >>tester class.

      As written, this is all reasonable to me, but I can see it easily
      being misinterpreted, so I'm gonna jump right in. Note that
      none of this is in opposition, exactly, to what Kevin said, just
      different phrasing/attitude.

      My view is that:
      Functional tests exist to satisfy us that a user story is being met.
      Unit tests exist to maximize developer mobility.

      We are not *seeking* 100% coverage with unit tests. Rather, that
      or close to it is what we usually get.

      We are not seeking one test per interesting method, and here
      we actually usually produce many more than just one. (This
      difference in view may be an artifact of our testing frameworks:
      Mine uses many short testing methods rather than one long one.)
      Let's put it this way: A five-to-one ratio of test-lines to
      production-lines is not out of whack here.

      Retrofitting unit tests is quite difficult. The act of coding simple
      unit tests before coding the production that passes them makes
      rather substantial contributions to the design of your code. In
      the absence of that technique, your code may be formally correct
      while still quite difficult to unit test.

      Retrofits usually result in writing a unit test that is a kind of
      mini-functional test: you test the object you wanted and ALL
      objects anywhere in the system that it talks to. This is not
      generally desirable. What you really want is a test that works
      with just the one object. His correspondents you'll usually
      want to stub or fake. Resulting designs tend to create
      constructors that take correspondent& variables and init
      them. Then the unit test can construct the right kind of
      correspondent and pass it in.

      Retrofit from the bottom up rather than the top down. Tackle
      your primitive objects first. Try a few primitives, then take
      a broken one and fix it while still passing the other tests.
      You'll be amazed at the result, and the juice will help you
      refactor the rest of your code for testability.

      Another tip. Be sure to add a unit test any time you find
      a defect, before you fix that defect. Your unit tests will
      naturally grow to the correct size over time. Try noticing
      where the defects are. Over time, you'll be astonished
      at how many are located in the places you couldn't figure
      out how to test!

      Have fun, and ask us more specific questions as you go!


      |Michael Hill |
      |Software-> Developer, Consultant, Teacher, Coach |
      |Lifeware-> Egghead, Romantic, Grandpa, Communitarian |
      |<uly_REMOVE_THIS_PART_@...> |
    • Show all 66 messages in this topic