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

RE: [XP] Unit Testing and Accessibility

Expand Messages
  • Robert Watkins
    ... But, as I pointed out, I don t always have access to all the unit tests... Robert. -- This transmission is for the intended addressee only and is
    Message 1 of 17 , Nov 30, 2000
    • 0 Attachment
      Ron Jefferies writes:
      > When you vanish or repurpose a method, you run all the tests. If
      > they run,
      > no problem. If they do, you find the unintended use. You look at it.
      >
      > If the use turns out to be proper, you need to make the method stable. If
      > tit's used improperly, pair with the user and educate them. If you run
      > across a pure mistake, you and your pair fix it. Nema problema.

      But, as I pointed out, I don't always have access to all the unit tests...

      Robert.



      --
      This transmission is for the intended addressee only and is confidential
      information. If you have received this transmission in error, please
      delete it and notify the sender. The contents of this e-mail are the
      opinion of the writer only and are not endorsed by Mincom Limited unless
      expressly stated otherwise.
    • Robert Watkins
      ... So don t do that isn t an easy message to sell to my management. FWIW, we don t evolve both sides concurrently. My group writes framework code to be used
      Message 2 of 17 , Nov 30, 2000
      • 0 Attachment
        Ron Jefferies writes:
        > At 04:51 PM 11/30/2000 +1000, Robert Watkins wrote:
        > >(For internal stuff, I solve that worry with unit tests... but the code I
        > >work on is also used by another group. They've got unit tests too, but I
        > >can't run them. So a clearly defined interface which only changes between
        > >releases is fairly important)
        >
        > Doctor, it hurts when I split the groups and try to evolve on
        > both sides ...

        "So don't do that" isn't an easy message to sell to my management.

        FWIW, we don't evolve both sides concurrently. My group writes framework
        code to be used by several development groups internally... one such group
        is our customer, in XP terms, and they get to use the framework code under
        development, but the rest are definitely users. When we get the framework
        stabilised, we release, the development groups jump on it. But when we do
        another release, we need to have a clear idea of what interface changes have
        been made. Keeping public methods at an as-needed status helps us in that.

        (Oh, and I only get to see the unit tests from the other groups on a weekly
        basis...)

        Robert.



        --
        This transmission is for the intended addressee only and is confidential
        information. If you have received this transmission in error, please
        delete it and notify the sender. The contents of this e-mail are the
        opinion of the writer only and are not endorsed by Mincom Limited unless
        expressly stated otherwise.
      • Robert Watkins
        ... Hmm... perhaps I m not being clear. What I mean by a clearly defined interface is the What do I want this object to do? side. I make that public.
        Message 3 of 17 , Nov 30, 2000
        • 0 Attachment
          Dossy writes:
          > Phrases like "clearly defined interface" sound like too much design-ahead
          > going on. If your system has evolved into what you want to *call* a
          > "clearly defined interface" then by that point everyone should be
          > using it. If you're worried about the growing pains of evolving a
          > "clearly defined interface" and you DO run into one of these conditions
          > where you'd like to change a popular method which YOU felt shouldn't
          > be called directly, maybe YOU need to step back and think about whether
          > you should really be modifying that method vs. creating a new one,
          > refactoring out the code common to both methods, and leaving the old
          > method to do what it did and the new one to suit your needs.

          Hmm... perhaps I'm not being clear.

          What I mean by a "clearly defined interface" is the "What do I want this
          object to do?" side. I make that public. However, the How-Do-I-Do it side I
          keep (package) private.

          I like to keep the "What do I want" question clear and simple. Cluttering
          the interface of a class with "How Do I" methods is a pain (unless, of
          course, it's a utility class designed for that).

          Refactoring still occurs. It's a key step in our development process, and we
          usually evolve the clearly defined interfaces out of the refactoring...
          sometimes, we do it out of our test-driven design, but it's usually easier
          when there's a bit more meat to the body. We do this to avoid violating
          OAOO, and for TSTTCPW. Within an iteration, and even between releases, the
          clearly-defined interfaces fluctuate, but we do try and keep ones that have
          escaped out to other groups stable. For this reason, we try _very_ hard to
          keep them simple.

          As part of our design, we also tend to try to put more generic utility that
          would be re-used by non-related objects out to generic utility objects. This
          avoids the problem to a large extent. Indeed, when someone starts thinking
          that it'd be nice to use that method on the object over there, it's usually
          a code smell that something needs to be abstracted out to something more
          generic.

          Robert.



          --
          This transmission is for the intended addressee only and is confidential
          information. If you have received this transmission in error, please
          delete it and notify the sender. The contents of this e-mail are the
          opinion of the writer only and are not endorsed by Mincom Limited unless
          expressly stated otherwise.
        • Robert Watkins
          ... Do you have some peculiar obsession with avian lifeforms, Ron? Robert. (It s *teat*, damn it... a tit is a bird. A teat is part of one. ;0) -- This
          Message 4 of 17 , Nov 30, 2000
          • 0 Attachment
            Ron Jefferies writes:
            > At 08:03 AM 11/30/2000 -0500, Dossy wrote:
            > > > If the use turns out to be proper, you need to make the
            > method stable. If
            > > > tit's used improperly, pair with the user and educate them. If you run
            > >
            > >If anyone on this list knows anyone who faces the problem of improper
            > >tit usage, please send them my way. I'll pair with them and _educate_
            > >them. *heh, heh heh, heh*
            >
            > When I make a typo, it's a good one. Those who know me would be whipping
            > out their copy of Freud right now.
            >
            > I laughed and laughed.

            Do you have some peculiar obsession with avian lifeforms, Ron?

            Robert.

            (It's *teat*, damn it... a tit is a bird. A teat is part of one. ;0)



            --
            This transmission is for the intended addressee only and is confidential
            information. If you have received this transmission in error, please
            delete it and notify the sender. The contents of this e-mail are the
            opinion of the writer only and are not endorsed by Mincom Limited unless
            expressly stated otherwise.
          Your message has been successfully submitted and would be delivered to recipients shortly.