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

RE: [XP] Testing Is Hard - Wuestion

Expand Messages
  • Ron Jeffries
    ... Unit tests are the probes of your meters. You can and should put them on any spot in the object that can tell you what you need to know. Black, white,
    Message 1 of 23 , Sep 1, 2000
    • 0 Attachment
      At 01:57 PM 9/1/00 +1000, Robert Watkins wrote:
      >It was part of a general discussion we (the project team I was on) were
      >having with respects to unit testing. We had two basic camps: a group that
      >wanted to do black-box testing, and a group that wanted white-box testing.
      >The big concern I had with the black-box testing was that it meant we were
      >exposing inner details of the object when that wasn't appropriate.

      Unit tests are the probes of your meters. You can and should put them on
      any spot in the object that can tell you what you need to know. Black,
      white, pink, doesn't matter. If right now you want to know that the voltage
      across the frammis is 37, or right now you want to know that there are
      three unique keys in the stack index auxiliary table, find out. The test is
      there to get you to the next step, and to keep the object working when it's
      changed.

      As you begin with test-first, write whatever keeps you moving. Trust that
      you will learn what works best. The sky won't fall if you expose too much
      stuff once in a while, and over time it won't happen enough to worry about.

      >Exposing the details at the package level was a technical solution for the
      >problem, as we are using Java. I'm not sure what I would do if I was working
      >in a language that didn't give me this facility (do Smalltalk classes have
      >friends?)

      In Smalltalk, labeling a method "private" is a comment. In an environment
      of collective code ownership (are you doing that one?) if someone needs the
      method they'll expose it. If someone uses the wrong method by mistake (and
      for some reason their partner doesn't notice (are you doing that one?)) the
      next pair will fix it.

      And it really doesn't matter anyway. Is someone using the stack index
      auxiliary table even though it's private? When we remove it, their tests
      won't run. We'll discover we shouldn't remove it. Or we'll fix their code
      to do the right thing.

      All that privacy stuff we used to get so hot about Just Doesn't Matter.
      Wonderful, another thing not to get stressed about. We don't have to police
      all the other programmers any more. Life is good.



      Ronald E Jeffries
      http://www.XProgramming.com
      http://www.objectmentor.com
    • Jim Little
      From: Ron Jeffries ... police ... I ve just discovered how true this is. I ve been working with a design for a while now that tried
      Message 2 of 23 , Sep 1, 2000
      • 0 Attachment
        From: "Ron Jeffries" <ronjeffries@...>
        > All that privacy stuff we used to get so hot about Just Doesn't Matter.
        > Wonderful, another thing not to get stressed about. We don't have to
        police
        > all the other programmers any more. Life is good.

        I've just discovered how true this is. I've been working with a design for
        a while now that tried very hard to keep access permissions in order. The
        net result was a ridiculously complicated design, because the persistence
        layer *had* to get at an object's private data. Since exposing private data
        is "bad," I didn't do that -- instead, I used a convoluted scheme involving
        inner classes to provide a "kosher" interface to the private data. It
        worked great, except that writing tests and code took twice (at least) as
        long as it should have. Oh, and nobody could figure it out unless I was
        standing there mentoring them.

        Thanks to the advice of another programmer down here, I recently gave up my
        attempts to police the programmers. We're currently ditching all of our
        complicated inner classes and making our fields public. We're just
        starting, but already the benefits are remarkable. We traded an immensely
        complex design approach for one line of text on the whiteboard: "Thou shalt
        not access instance variables unless thou art a test or a forklift
        [persistence layer code]." And that was it.

        So, um, the point here -- what he said.

        Jim

        (But I think I would be more wary of this approach if we didn't have
        pair-programming and tons of tests.)
      Your message has been successfully submitted and would be delivered to recipients shortly.