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

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

Expand Messages
  • Manuel Klimek
    Alain, ... I live collective code ownership by skimming through the changes when I update my working copy. This is by no means a real code review, but
    Message 1 of 184 , Jun 1, 2007
    • 0 Attachment
      Alain,

      On 6/1/07, Desilets, Alain <alain.desilets@...> wrote:
      > I never do them. I figure pair programming and collective ownership
      > provide plenty of oppurtunity for impromptu code reviews.

      I "live" collective code ownership by skimming through the changes
      when I update my working copy. This is by no means a real code
      review, but sometimes I find issues and I stay up to date about the
      current state of the code base, which is in my eyes an important
      part of collective code ownership.

      > 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.

      In my experience I find different bugs with code reviews than with
      testing. The code reviews help for higher level issues,
      communication bugs: If I don't understand what tests to write
      without knowing that I don't understand it, I'll write the wrong tests.
      It's the old question of "build the right thing".

      A domain expert may often just "see" that something is wrong
      even when only viewing a view diffs.

      Additionally I don't think that for me pair programming suffices
      to catch all the design issues. Sometimes after a pair checked
      in the code you won't look at the code again until either a bug
      was detected or an additional feature is requested.

      Cheers,
      Manuel

      --
      http://klimek.box4.net
    • 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.