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

RE: [XP] Code Reviews [was: Isolation and Mocks]

Expand Messages
  • Desilets, Alain
    ... I never do them. I figure pair programming and collective ownership provide plenty of oppurtunity for impromptu code reviews. Speaking of code reviews.
    Message 1 of 184 , Jun 1, 2007
    • 0 Attachment
      > How many out there do code reviews (of some form) regularly?

      I never do them. I figure pair programming and collective ownership
      provide plenty of oppurtunity for impromptu code reviews.

      Speaking of code reviews.

      Almost everytime I make a presentation on TDD to an audience of 20
      people or more, there is someone in the audience who objects that
      research has proven that code reviews are a more effective way of
      finding bugs than testing.

      That goes completely counter to my own experience. I am simply unable to
      find bugs by reading the code. But with TDD, my tests intercept at least
      one non-trivial bug (i.e. a bug that happens out of the blue) per hour.

      Is there someone on this list who is familiar with that body of research
      who can explain this apparent contradiction? I haven't read it, but I
      have an hypothesis. I bet that this research compared early code
      inspection (i.e. early as in code is inspected soon after it was
      written) to late, manual, infrequent, black-box testing. I can believe
      that code inspection might be more effective in that situation. But I
      can't see how more modern TDDstyle (i.e. automated, 100 times per day,
      white-box) testing would be less efficient than code inspection.

      One thing I find inspections good for though is finding design flaws (as
      opposed to bugs). But like I said, I find pair-programming and
      collective ownership provides ample opportunity for that to happen.

      Any thoughts or opinions on this?

      Alain
    • Steve Freeman
      ... Now I m lost. I have a test that exercises a feature. Inside that test, some things are there for infrastructure and some things are there because they
      Message 184 of 184 , Jun 28, 2007
      • 0 Attachment
        On 25 Jun 2007, at 10:40, Paul Campbell wrote:
        > --- In extremeprogramming@yahoogroups.com, Steve Freeman
        > <smgfreeman@...> wrote:
        >>
        >> The issue for me is the intent I'm trying to express.
        >>
        >> I set expectations (a.k.a. mock) where I want to assert something
        >> about the behaviour. I stub where I just want the test to get through
        >> the code to the interesting stuff.
        >
        > I get that distinction and it seems a useful one BUT I still dont like
        > the terminology. It would make more sense to me to categorise the type
        > of test being done rather than the type of object being used as the
        > "double" or whatever.

        Now I'm lost. I have a test that exercises a feature. Inside that
        test, some things are there for infrastructure and some things are
        there because they show that the feature works. What would different
        types of test look like?

        S.

        Steve Freeman
        http://www.mockobjects.com

        Winner of the Agile Alliance Gordon Pask award 2006
      Your message has been successfully submitted and would be delivered to recipients shortly.