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

87233Re: [XP] re: XP, unit testing and accepted failures

Expand Messages
  • Sean Gilbertson
    Dec 31, 2003
    • 0 Attachment
      Ah yes, the mock object. That seems to slip out of
      my consciousness once in a while (as I said, I'm still
      getting used to XP ;-).

      But, your most helpful comment was the confirmation
      of my inclination to treat it as a real defect. "But
      how to deal with that?" I thought. You say, "with
      ACCEPTANCE tests." That sounds very reasonable, and
      fits the framework. However, let me pose a scenario:
      I decide to handle a disconnect. This in turn fails
      the actual unit test. What then? Basically, my
      concern is for those situations where you simply
      cannot guarantee success (in a reasonable manner.. I
      would be lenient in a situation where memory capacity
      is not a concern) -- unit testing seems to take the
      approach that you can guarantee success through the
      presence of 100% code-coverage testing. It occurs to
      me now, though: unit testing IS for ideal situations,
      in some respects (i.e., the network). However, XP has
      not told me (yet) how to deal with failure.

      That was pretty roundabout, but you did reassure me
      and give me plenty to think about. Thank you!

      - Sean

      --- John Brewer <jbrewer@...> wrote:
      > > I'm just getting into XP and unit testing, and
      > I like what I see
      > >(particularly the book "Agile Software
      > Development"), however I have a
      > >question: How does unit testing view acceptable
      > failures, such as a
      > >class being unable to connect to a remote host? I
      > can tell that some
      > >things are assumed to work (i.e., not running out
      > of memory), but how
      > >far does this extend? Should I make judgement
      > calls? I have some
      > >reservations about assuming disk writes will go as
      > planned, and I'm
      > >hesitant to the point of immobility to accept that
      > network connections
      > >will be peachy.
      > For unit tests, you want to isolate the class under
      > test, and control
      > its environment completely. The usual way to do
      > this is to abstract
      > out interfaces for the classes the class under test.
      > Then you can
      > plug in a so-called "mock object" that implements
      > that interface, but
      > fakes the implementation. Then you can have your
      > mock object either
      > work or as needed, so you can test your class's
      > behavior in both
      > cases.
      > For acceptance tests and overall system tests, I'd
      > treat the systems
      > inability to deal with a network or disk space
      > failure as a system
      > failure. I'd probably also get together with a
      > suitably sadistic QA
      > person, and figure out how to repeatably cause such
      > a network or disk
      > failure, so that we could test the system's response
      > to the situation
      > via an automated test suite.
      > --
      > John Brewer
      > Jera Design
      > Extreme Programming FAQ:
      > http://www.jera.com/techinfo/xpfaq.html
      > To Post a message, send it to:
      > extremeprogramming@...
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      > To visit your group on the web, go to:
      > http://groups.yahoo.com/group/extremeprogramming/
      > To unsubscribe from this group, send an email to:
      > extremeprogramming-unsubscribe@yahoogroups.com
      > Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/

      Do you Yahoo!?
      Free Pop-Up Blocker - Get it now
    • Show all 10 messages in this topic