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

Re: [XP] Testing vs Inspection

Expand Messages
  • jhrothjr
    ... I m not sure what Watts beliefs are. What I had heard in the early 70s when formal inspections and Cleanroom were being formulated was that anything you
    Message 1 of 70 , Sep 1, 2004
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "Jeff Grigg"
      <jeffgrigg@c...> wrote:
      > >>> I take Kari's point to be similar to the one that Watts
      > >>> Humphrey made to me. Watts' belief is:
      > >>>
      > >>> If we manually check our code before compiling and
      > >>> removing the syntax errors that the compiler (or
      > >>> IDE) would find, we will //also// find other logic
      > >>> errors, owing to the extra scrutiny, that the
      > >>> compiler would not find.

      I'm not sure what Watts' beliefs are. What I had heard in the
      early '70s when formal inspections and Cleanroom were being
      formulated was that anything you could describe you could inspect
      for. The notion of letting the compiler catch syntax errors first was
      rejected as not being cost effective: it was cheaper to let the
      inspection team catch them, and it encouraged people to write
      syntactically clean code the first time. I suspect this encourages
      people to take care with what they write, rather than trusting to
      later work to clean up the mess.
      > > --- Randy MacDonald wrote:
      > >> As I may have said before, up-front tests provide this
      > >> scrutiny at silicon speed, eventually covering anything
      > >> the language designers have yet to implement. The
      > >> benefits of a manual scan do not justify the extra time
      > >> and effort.
      > Test Driven Development (TDD) is good at catching functional
      > regression. But it doesn't detect code smells. People still have
      > to do that.

      That's an interesting point, although I believe that people are hard
      at work on writing code that can detect some kinds of code smells. So
      I'm not going to get all doctrinaire about "people have to do this
      kind of thing." Over time, I think this is simply not going to be

      > --- Ron Jeffries <ronjeffries@X...> wrote:
      > >>> I do know that my code, with TDD, is very free of
      > >>> defects compared to what I used to write with
      > >>> nothing but compiler diagnostics and sporadic
      > >>> testing to help me.
      > Me too. And my code was /very/ good before.
      > --- Ron Jeffries <ronjeffries@X...> wrote:
      > > My code is better when I TDD, but it is emphatically not
      > > perfectly bug-free. It seems likely that if I were able
      > > to pay more attention, it would be better.
      > Me too. I read that people have been successful with the Clean
      > methodology. From what I read, it seems to make sense that they
      > could. I think I could successfully do Clean Room, and get similar
      > results. Better results than XP? Well, that's not clear. Higher
      > productivity and/or a more enjoyable work environment? Well, I
      > doubt it. But I haven't done it (and have no current plans to try
      > it) so I can't be really sure.
      > > I'm not doing intense scrutiny, nor even recommending it.
      > > But I do think it's unwise to dismiss it.
      > Maybe a higher level of scrutiny that would be better. Maybe there
      > could be a sensible way to integrate this with XP. If someone
      > figures out how to do that successfully, I'd be glad to hear about
      > it.

      I certainly don't think it can be done, for the simple reason that
      formal inspections as defined in Cleanroom simply don't fit into the
      TDD workflow. Formal inspections are a practice that fits very well
      into the workflow of standard plan driven methods, though.

      On the other hand, generic automated checks (such as the smell
      detectors that people are working on) could be integrated very well.
      It should be possible to integrate some kind of more general
      specification checking (other than tests), but I don't know of anyone
      working on it.

      The key is automation that doesn't get in the way of the TDD workflow.

      John Roth
    • Kari Hoijarvi
      Thanks, I add it to my tool list to check out. Kari ... From: Williams, Chris [mailto:chris.williams@crt.xerox.com] ... In the absence of peer code reviews, I
      Message 70 of 70 , Sep 2, 2004
      • 0 Attachment
        Thanks, I add it to my tool list to check out.


        -----Original Message-----
        From: Williams, Chris [mailto:chris.williams@...]

        > good up to certain point. Finding bugs with adding tests later is
        > notoriously inefficient. Reviews rock.

        In the absence of peer code reviews, I found FindBugs to be helpful. Caught
        many gaffes of mine with equals(), hashCode(), exposing internal objects,
        waits and notifies, etc.


        I definitely recommend it for the Java folks out there. I use it
        intermittently to just double-check myself, since my workplace doesn't do XP
        (gasp!) or code reviews.

      Your message has been successfully submitted and would be delivered to recipients shortly.