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

RE: [XP] Acceptance tests in Adventures in C#

Expand Messages
  • Andrei GHEORGHE
    ... Well, we have 2 parts: 1. Open the dialog and set the controls data and then click ok 2. execute the find The customer(?) test that I ve proposed is
    Message 1 of 31 , Dec 5, 2002
    • 0 Attachment
      > -----Original Message-----
      > From: Ron Jeffries [mailto:ronjeffries@...]
      > Sent: Thursday, December 05, 2002 1:21 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Acceptance tests in Adventures in C#
      >
      >
      > On Thursday, December 5, 2002, at 4:18:10 AM, Andrei GHEORGHE wrote:
      >
      > > Ron Jeffries wrote:
      > >>Actually I think it is just fine as an acceptance test. Once that
      > >>framework accepts all the options of the dialog, it only remains to
      > >>test that the dialog produces the same information, in the way that
      > >>the user expects. So we could create one invisible dialog
      > and use it.
      >
      > > It does not test the dialog and it does not test the link
      > between the dialog
      > > and the model. It tests only the model.
      >
      > > It tests something that the user never runs directly. The
      > user will not use
      > > the find engine directly. I thought that a customer test is
      > a test that
      > > simulates exactly what the user does in a normal editing
      > session. Maybe I am
      > > wrong (?)
      >
      > What does "test the dialog" mean to you?
      >

      Well, we have 2 parts:
      1. Open the dialog and set the controls' data and then click ok
      2. execute the find

      The customer(?) test that I've proposed is testing only 2. If I have a class
      named FindEngine, that customer test is, in fact, a very good unit test.

      You are asking wat means testing the dialog. That means what could go wrong
      with 1, and what are some possible tests.

      Well, for example, I want to test that pressing <OK> will actually start the
      search.

      I want to test that <OK> will start the search with the data from the
      dialog(that is the data was corectly retreived from the dialog).

      I want to test that we can press <OK>. It might be a good idea to invalidate
      the OK button if there is no text in the TextBox. I want to test that when
      there is some text in there, the button is enabled.

      And there are others examples.

      But, all these (testing the model, testing the dialog), in my opinion, are
      unit tests, not customer tests.

      As a customer I'm interested in the feature as a whole, and I want to test
      it as a whole. I don't care that there is a model and I can run the
      operation only on the model.

      Of course, IMHO :)

      What do you think?

      Andrei.
    • Andrei GHEORGHE
      ... Well, we have 2 parts: 1. Open the dialog and set the controls data and then click ok 2. execute the find The customer(?) test that I ve proposed is
      Message 31 of 31 , Dec 5, 2002
      • 0 Attachment
        > -----Original Message-----
        > From: Ron Jeffries [mailto:ronjeffries@...]
        > Sent: Thursday, December 05, 2002 1:21 PM
        > To: extremeprogramming@yahoogroups.com
        > Subject: Re: [XP] Acceptance tests in Adventures in C#
        >
        >
        > On Thursday, December 5, 2002, at 4:18:10 AM, Andrei GHEORGHE wrote:
        >
        > > Ron Jeffries wrote:
        > >>Actually I think it is just fine as an acceptance test. Once that
        > >>framework accepts all the options of the dialog, it only remains to
        > >>test that the dialog produces the same information, in the way that
        > >>the user expects. So we could create one invisible dialog
        > and use it.
        >
        > > It does not test the dialog and it does not test the link
        > between the dialog
        > > and the model. It tests only the model.
        >
        > > It tests something that the user never runs directly. The
        > user will not use
        > > the find engine directly. I thought that a customer test is
        > a test that
        > > simulates exactly what the user does in a normal editing
        > session. Maybe I am
        > > wrong (?)
        >
        > What does "test the dialog" mean to you?
        >

        Well, we have 2 parts:
        1. Open the dialog and set the controls' data and then click ok
        2. execute the find

        The customer(?) test that I've proposed is testing only 2. If I have a class
        named FindEngine, that customer test is, in fact, a very good unit test.

        You are asking wat means testing the dialog. That means what could go wrong
        with 1, and what are some possible tests.

        Well, for example, I want to test that pressing <OK> will actually start the
        search.

        I want to test that <OK> will start the search with the data from the
        dialog(that is the data was corectly retreived from the dialog).

        I want to test that we can press <OK>. It might be a good idea to invalidate
        the OK button if there is no text in the TextBox. I want to test that when
        there is some text in there, the button is enabled.

        And there are others examples.

        But, all these (testing the model, testing the dialog), in my opinion, are
        unit tests, not customer tests.

        As a customer I'm interested in the feature as a whole, and I want to test
        it as a whole. I don't care that there is a model and I can run the
        operation only on the model.

        Of course, IMHO :)

        What do you think?

        Andrei.
      Your message has been successfully submitted and would be delivered to recipients shortly.