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

RE: [XP] Re: Adventures in C#: Digression -- WordCount

Expand Messages
  • Charlie Poole
    Mike, ... That s cool. I d like to see what you come up with. As some more food for thought, here s why I didn t think you d explained the need for
    Message 1 of 37 , Jan 1, 2003
    • 0 Attachment
      Mike,

      > > Which is why I ask again... please show me something you need
      > > to test that requires the asynchronous call...
      >
      > I thought I just did, with the echo server example, but we have a
      > philosophical misunderstanding, that's all. I don't believe in the
      > unit test/customer test way of thinking. I believe you need a
      > continuum of tests. I was trying to use NUnit for partial system
      > testing. Since I'm just getting started with NUnit and TDD, I'm not
      > completely sure that pushing NUnit that far is a good idea. I'd like
      > to try other solutions and experiment some more.

      That's cool. I'd like to see what you come up with.

      As some more food for thought, here's why I didn't think you'd
      explained the need for asynchronous testing.

      The echo server will clearly respond asynchronously. And if you
      were testing it, you'd need at least one asynchronous test to
      see that it had in fact responded. But of course you're not
      testing the echo server... you're testing a client.

      What I was asking is what do you need to test about your own
      client-side object that requires making an asynchronous call
      to it? Specifically.

      Btw, I'm suspecting that you took my asking as a rhetorical device
      to "show you" you don't need asynchrous tests. That wasn't my
      intent. I have a gut feel that we may need some kinds of
      asynchronous unit tests, but that we should be able to define
      a rather limited set of circumstances where we need them just
      as we do for guis. Parsing out the exact setting where you
      need this would help me understand.

      I'd agree with you that many systems need a whole range of
      tests at different levels of granularity. But this is quite
      different from the XP distinction of programmer and customer
      tests, which have to do with /who/ is responsible for their
      definition, not with their granularity. Of course, customers
      are usually interested in high level tests, but not always.
      For example, I've had customers require detail test output
      of cardiogram filtering output that lies deep inside the
      application and is never exposed to a user. And programmers
      usually see the need - as you do - for system tests,
      performance tests, etc.

      I think many people have used xUnit frameworks for various
      kinds of tests, including those in which the lower-level
      objects report back asynchronously. Usually that's done
      by pointing the tests at a higher-level object - either
      an actual applicaton object or a mock object - that
      resolves the asynchronicity in some way. In fact that's
      how NUnit's own tests work. But if you get to the point
      where you can imagine some framework feature that would
      make it easier, let us hear about it.

      Charlie Poole
      cpoole@...
      www.pooleconsulting.com
      www.charliepoole.org
    • Charlie Poole
      Ron, ... Gee, you said that so much more succinctly than I did... usually I read ahead before replying. Charlie Poole cpoole@pooleconsulting.com
      Message 37 of 37 , Jan 1, 2003
      • 0 Attachment
        Ron,

        > > I thought I just did, with the echo server example, but we have a
        > > philosophical misunderstanding, that's all. I don't believe in the
        > > unit test/customer test way of thinking. I believe you need a
        > > continuum of tests. I was trying to use NUnit for partial system
        > > testing. Since I'm just getting started with NUnit and TDD, I'm not
        > > completely sure that pushing NUnit that far is a good idea. I'd like
        > > to try other solutions and experiment some more.
        >
        > Yes, definitely, you do need a continuum of tests. And you're right to
        > experiment to find your own sweet spot.
        >
        > In XP, the programmer test / customer test distinction serves a different
        > purpose. Programmer tests provide confidence and mobility to the
        > programmers.
        > Customer tests provide confidence to the customers, and information about
        > requirements to the programmers.
        >
        > Those two forms of tests are there to provide balance between
        > programmer and
        > customer subteams. Wise programmers have a broad enough continuum
        > of tests to
        > make failure in the customer tests very rare. This increases
        > customer confidence
        > in the team. That's a very good thing.

        Gee, you said that so much more succinctly than I did... usually
        I read ahead before replying.

        Charlie Poole
        cpoole@...
        www.pooleconsulting.com
        www.charliepoole.org
      Your message has been successfully submitted and would be delivered to recipients shortly.