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

RE: [XP] Re: Test execution speed

Expand Messages
  • Steve Bate
    ... Even some of the mock implementations of mockobjects.com doesn t fit our definition of a mock because they implement some simple domain-related behavior in
    Message 1 of 260 , Aug 2, 2004
      > From: Dominic Williams [mailto:yg_xp@...]
      > > You are using the term "stubbing" here in addition to
      > > mocking. How do you define those terms?
      >
      > It sounds as though I use the term "stub" for what you
      > call a mock. I use the word "mock" for stubs that are
      > developped using a framework such as mockobjects.com,
      > or even generated with a tool such as easymock.org. I
      > think they are interchangeable for the purpose of this
      > discussion.

      Even some of the mock implementations of mockobjects.com
      doesn't fit our definition of a mock because they implement
      some simple domain-related behavior in places (and it's
      burned us a few times).

      > ...
      > > Could you give some examples of how mocking leads to
      > > highly coupled designs?
      >
      > As I already said in my response to Ron, I did not say
      > that mocking leads to that. I said that mocking allows
      > it.

      I believe it's more challenging to create highly coupled
      designs when classes interact through abstractions rather
      than concrete implementations. Mock-based testing
      encourages the former in my experience.

      >...
      > > This is one force that leads to a Repository
      > > abstraction and associated mocks rather than
      > > depending directly on JDBC or file access code.
      >
      > Long before mock objects were all the craze they now
      > are, vanilla XP unit testing had already lead me to
      > that pattern.

      My point was that the mock-based testing is other
      force that seems to lead developers (especially less
      experienced developers) down this path more quickly.
      I wasn't saying that one couldn't discover the Repository
      pattern without mocks.

      > > When doing TDD, I find it valuable to be able to
      > > focus on the class I'm designing and the abstractions
      > > it depends upon rather than having to design the
      > > implementation of all dependent, concrete classes at
      > > the same time.
      >
      > Are you really doing TDD if to implement a class, you
      > already need several other classes? Isn't the TDD way
      > to just make it pass (faking or hard-coding if
      > necessary), then refactor?
      >
      > If you are working on a very small story, where does
      > the need for all these dependent, concrete classes come
      > from? What's happened to YAGNI? You just put all the
      > code in one class, for starters. Breaking it down into
      > several classes comes from doing subsequent stories.

      After the first story, aren't you always doing subsequent
      stories? We are many thousands of stories into development
      at this point. Maybe we aren't doing TDD the way everyone
      else does, but we tend to start refactoring early on
      (during TDD) rather than waiting until we have a big
      monolithic class implementation. We definitely try to
      avoid reimplementing code that's already implemented in
      existing classes when doing TDD.

      Well, I have to run off to catch a flight. Thanks for the
      discussion.

      Steve
    • Ilja Preuss
      ... Yes, but I thought that we were talking about a test that was wrong. Not sure wether that matters, though... Cheers, Ilja
      Message 260 of 260 , Aug 18, 2004
        Adrian Howard wrote:
        > On 17 Aug 2004, at 12:22, Ilja Preuss wrote:
        > [snip]
        >> It's certainly the case that without pairing/reviews I am more
        >> likely to
        >> *miss* tests - but I don't think that I get more *wrong* tests that
        >> cancel out with wrong implementation...
        >
        > I think it could happen over time.
        >
        > - Lack of pairing might mean I miss duplication so a bit
        > of business logic gets into foo and bar.
        >
        > - My acceptance test for the business logic only uses foo.
        >
        > - Later I change bar incorrectly, but the foo test still passes.
        >
        > False-pass for that bit of business logic.

        Yes, but I thought that we were talking about a test that was wrong. Not
        sure wether that matters, though...

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