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

RE: [XP] write customer tests first

Expand Messages
  • Amir Kolsky
    ... First of all, a phrase like the cutomer might not be happy isn t part of our vernacular. You cannot have members of your community unahppy in XP, at
    Message 1 of 35 , Nov 2, 2004
    • 0 Attachment
      >Why don´t you remove the customer tests in these cases? OK,
      >the customer might not be very happy if the tests he wrote
      >were removed... But we run the unit tests much more often then
      >the customer tests. In particular when we release new code, we
      >run all the unit tests on the integration machine but not
      >always all the customer tests. So wouldn´t it be saver to keep
      >the unit tests and replace the customer tests?
      >

      >Christoph

      First of all, a phrase like "the cutomer might not be happy" isn't part of
      our vernacular. You cannot have members of your community unahppy in XP, at
      least not for long.

      So, why is the customer unhappy?

      The customer is unhappy because you did away with his specifications. You
      did away with his way of ensuring that the product he needs is what he gets.

      Remember - A story is complete when the story test passes. This is the proof
      of acceptance by the customer. If the test passes the customer can't
      complain that what you did was wrong. He may change his mind, or expand on
      the original story, but this will be accompanied by revised or new story
      tests.

      So how do you use these customer tests to guide the design, like you do with
      unit tests? Well, to begin with there's the issue of the test fixtures that
      exercise your code in the story tests. These can be tied to the unit testing
      framework so that when the unit tests run, they actually execute the story
      tests. Secondly, if there are things that you know that you need to assert
      in the unit tests and are not customer issues and hence have no place in the
      story tests (For example, ensuring that files are closed), you can build
      your story test fixture to allow you to make these assertions.

      What we usually see is that we start developing with story tests to guide
      our unit tests. In some cases we see that the unit tests are exactly like
      the story tests in these cases we fold the unit testing functionality into
      the story test fixture.

      The reason why to split the two is that you, as the developer, have insight
      into your code. A complicated customer test, given the current design of
      your system may be a simple unit test for you, so the two are not the same.

      Anyway, you should never have your customer unahppy. You're the developer,
      if you want to do away with something, do away with the unit tests, not the
      story tests.

      Amir
      Xpand Software...
    • Amir Kolsky
      Yup Amir Kolsky XP& Software
      Message 35 of 35 , Nov 6, 2004
      • 0 Attachment
        Yup

        Amir Kolsky
        XP& Software


        >-----Original Message-----
        >From: Kent Beck [mailto:kentb@...]
        >Sent: Sunday, November 07, 2004 6:16 AM
        >To: extremeprogramming@yahoogroups.com
        >Subject: RE: [XP] write customer tests first
        >
        >
        >I misunderstood you. My mistake. What I hear you saying now is
        >that if people are unhappy on an XP team there are serious
        >consequences. Is that accurate?
        >
        >Kent Beck
        >Three Rivers Institute
        >
        >> -----Original Message-----
        >> From: Amir Kolsky [mailto:kolsky@...]
        >> Sent: Friday, November 05, 2004 11:32 AM
        >> To: extremeprogramming@yahoogroups.com
        >> Subject: RE: [XP] write customer tests first
        >>
        >>
        >>
        >> I said: "You cannot have members of your community unahppy in XP, at
        >> least not for long." It is a matter of fact that some people
        >might be
        >> unhappy as a result of someone's actions, be it you or someone else.
        >> For example, if some new guy gets hired and he happened to sit by a
        >> CRT screen when everyone else has LCD, he'll probably be
        >unhappy. But
        >> that's acceptable. The tradeoffs between reality and happiness are
        >> always there... However, you cannot have any single member of your
        >> community unhappy for a long time as this will cause your team to be
        >> inaffective, or that person to leave.
        >>
        >> One of the worse things you can do is alienate your customer.
        >> Especially if that customer is one of many (which is
        >something that we
        >> have ran across recently). If a customer is consistently ignored he
        >> will be unhappy. You have to indulge that customer in the planning
        >> game (as the lead customer, that is) or he might turn
        >against you. In
        >> our case a customer was trying to do things the XP way (from his
        >> perspective) which went against the wish of another major player. He
        >> lost every time. Eventually he started to voice concerns that the
        >> whole project is going to fail. We had a tough time (As
        >> coaches) to make people understand that even though what he
        >asked for
        >> might not be the *exact* right thing to do next, it was the
        >> politically correct thing to do, and since this calmed
        >things down in
        >> the group, it had business value.
        >
        >
        >
        >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
        >
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.