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

Test de-coupling

Expand Messages
  • Kenig, Neil
    Thanks for the recent responses on Excel testing. I was just reading Keith Ray s blog on testing http://homepage.mac.com/keithray/blog/2005/12/04/:
    Message 1 of 8 , Dec 5, 2005
    • 0 Attachment
      Thanks for the recent responses on Excel testing. I was just reading
      Keith Ray's blog on testing
      http://homepage.mac.com/keithray/blog/2005/12/04/:

      "Fortunately for people doing incremental design work with refactoring,
      most automated tests do not have to change when the code is changed. The
      tests are acting as executable specifications for the requirements, so
      if the requirements haven't changed, then the tests should not have to
      change. Of course, when the tests are very close to the implementation,
      they do sometimes need to be change, but the majority of tests should
      not change when someone need to alter the design to handle requirements
      being address in the current iteration."

      (This is an oversimplification but it makes the point.) We have an
      application that takes 137 inputs and produces a single output. We have
      tests that test the various inputs against the output. For example, one
      input may be a 5 choice selection - there will be tests to make sure
      that the output is correct for each of the five input choices. The
      problem is that a change in (calculation of the output due to) any of
      the 137 inputs necessarily changes the output for all of the inputs
      hence all of the tests change. Adding inputs (which change the result)
      and changing the calculations on existing inputs is common, resulting in
      the need to change virtually every test.

      Any suggestions?

      Neil Kenig
      PRICE Systems, L.L.C.


      Attention: PRICE Systems, L.L.C. maintains a safe computing environment but accepts no liability for any unintended effects arising from your receipt of data originating from PRICE Systems including this email and its attachments. Unintended effects include, but are not limited to, loss of data or service due to harmful or malicious software such as computer viruses. Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. PRICE Systems accepts no liability for any damage caused by any virus transmitted by this email. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.



      [Non-text portions of this message have been removed]
    • Keith Ray
      Is the single output a single number, or is this a report-generation program (or something like Excel)? The posting below talks about some filter functions I
      Message 2 of 8 , Dec 5, 2005
      • 0 Attachment
        Is the single output a single number, or is this a report-generation
        program (or something like Excel)?

        The posting below talks about some filter functions I worked on that
        had about 7 inputs (not including the image itself), each inputs
        having 2 to 10 possible values, others having potentially infinite
        possible values...

        <http://homepage.mac.com/keithray/blog/2005/09/28/>
        "...Then I wrote 900 one-line unit tests to this parameterized unit
        test with the various permutations of the input parameters and
        expected output values. (I actually worked in a spreadsheet for a
        while and copied-pasted from the spreadsheet to the unit test source
        code.) The test would also generate the output PDF file, which I
        could visually examine...


        On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:

        > Thanks for the recent responses on Excel testing. I was just reading
        > Keith Ray's blog on testing
        > http://homepage.mac.com/keithray/blog/2005/12/04/:
        >
        > "Fortunately for people doing incremental design work with
        > refactoring,
        > most automated tests do not have to change when the code is
        > changed. The
        > tests are acting as executable specifications for the requirements, so
        > if the requirements haven't changed, then the tests should not have to
        > change. Of course, when the tests are very close to the
        > implementation,
        > they do sometimes need to be change, but the majority of tests should
        > not change when someone need to alter the design to handle
        > requirements
        > being address in the current iteration."
        >
        > (This is an oversimplification but it makes the point.) We have an
        > application that takes 137 inputs and produces a single output. We
        > have
        > tests that test the various inputs against the output. For
        > example, one
        > input may be a 5 choice selection - there will be tests to make sure
        > that the output is correct for each of the five input choices. The
        > problem is that a change in (calculation of the output due to) any of
        > the 137 inputs necessarily changes the output for all of the inputs
        > hence all of the tests change. Adding inputs (which change the
        > result)
        > and changing the calculations on existing inputs is common,
        > resulting in
        > the need to change virtually every test.
        >
        > Any suggestions?
        >
        > Neil Kenig
        > PRICE Systems, L.L.C.
        >
        >
        > Attention: PRICE Systems, L.L.C. maintains a safe computing
        > environment but accepts no liability for any unintended effects
        > arising from your receipt of data originating from PRICE Systems
        > including this email and its attachments. Unintended effects
        > include, but are not limited to, loss of data or service due to
        > harmful or malicious software such as computer viruses. Computer
        > viruses can be transmitted via email. The recipient should check
        > this email and any attachments for the presence of viruses. PRICE
        > Systems accepts no liability for any damage caused by any virus
        > transmitted by this email. E-mail transmission cannot be guaranteed
        > to be secure or error-free as information could be intercepted,
        > corrupted, lost, destroyed, arrive late or incomplete, or contain
        > viruses. The sender therefore does not accept liability for any
        > errors or omissions in the contents of this message, which arise as
        > a result of e-mail transmission.
        >
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > 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
        >
        >
        >
        >
        >
        >
        >
      • Kenig, Neil
        Did you have an Excel model that mimicked the model in your code? Is that how you generated the 900 cases? If not, even though your unit test was
        Message 3 of 8 , Dec 5, 2005
        • 0 Attachment
          Did you have an Excel 'model' that mimicked the model in your code? Is
          that how you generated the 900 cases? If not, even though your unit
          test was parameterized, changing the results means changing some (most)
          of the 900 cases; that's quite a bit of maintenance.

          Neil.

          -----Original Message-----
          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
          Sent: Monday, December 05, 2005 10:45 AM
          To: extremeprogramming@yahoogroups.com
          Cc: agile-testing@yahoogroups.com
          Subject: Re: [XP] Test de-coupling

          Is the single output a single number, or is this a report-generation
          program (or something like Excel)?

          The posting below talks about some filter functions I worked on that had
          about 7 inputs (not including the image itself), each inputs having 2 to
          10 possible values, others having potentially infinite possible
          values...

          <http://homepage.mac.com/keithray/blog/2005/09/28/>
          "...Then I wrote 900 one-line unit tests to this parameterized unit test
          with the various permutations of the input parameters and expected
          output values. (I actually worked in a spreadsheet for a while and
          copied-pasted from the spreadsheet to the unit test source
          code.) The test would also generate the output PDF file, which I could
          visually examine...


          On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:

          > Thanks for the recent responses on Excel testing. I was just reading
          > Keith Ray's blog on testing
          > http://homepage.mac.com/keithray/blog/2005/12/04/:
          >
          > "Fortunately for people doing incremental design work with
          > refactoring, most automated tests do not have to change when the code
          > is changed. The tests are acting as executable specifications for the
          > requirements, so if the requirements haven't changed, then the tests
          > should not have to change. Of course, when the tests are very close to

          > the implementation, they do sometimes need to be change, but the
          > majority of tests should not change when someone need to alter the
          > design to handle requirements being address in the current iteration."
          >
          > (This is an oversimplification but it makes the point.) We have an
          > application that takes 137 inputs and produces a single output. We
          > have tests that test the various inputs against the output. For
          > example, one input may be a 5 choice selection - there will be tests
          > to make sure that the output is correct for each of the five input
          > choices. The problem is that a change in (calculation of the output
          > due to) any of the 137 inputs necessarily changes the output for all
          > of the inputs hence all of the tests change. Adding inputs (which
          > change the
          > result)
          > and changing the calculations on existing inputs is common, resulting
          > in the need to change virtually every test.
          >
          > Any suggestions?
          >
          > Neil Kenig
          > PRICE Systems, L.L.C.
          >
          >
          > Attention: PRICE Systems, L.L.C. maintains a safe computing
          > environment but accepts no liability for any unintended effects
          > arising from your receipt of data originating from PRICE Systems
          > including this email and its attachments. Unintended effects include,

          > but are not limited to, loss of data or service due to harmful or
          > malicious software such as computer viruses. Computer viruses can be
          > transmitted via email. The recipient should check this email and any
          > attachments for the presence of viruses. PRICE Systems accepts no
          > liability for any damage caused by any virus transmitted by this
          > email. E-mail transmission cannot be guaranteed to be secure or
          > error-free as information could be intercepted, corrupted, lost,
          > destroyed, arrive late or incomplete, or contain viruses. The sender
          > therefore does not accept liability for any errors or omissions in the

          > contents of this message, which arise as a result of e-mail
          > transmission.
          >
          >
          >
          > [Non-text portions of this message have been removed]
          >
          >
          >
          > 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 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
        • William Pietri
          ... I ve never dealt with anything that complex, but a good chunk of my tests for complex algorithms isolate particular conditions, so that most of the
          Message 4 of 8 , Dec 5, 2005
          • 0 Attachment
            Kenig, Neil wrote:

            >[...] We have an
            >application that takes 137 inputs and produces a single output. We have
            >tests that test the various inputs against the output. For example, one
            >input may be a 5 choice selection - there will be tests to make sure
            >that the output is correct for each of the five input choices. The
            >problem is that a change in (calculation of the output due to) any of
            >the 137 inputs necessarily changes the output for all of the inputs
            >hence all of the tests change. Adding inputs (which change the result)
            >and changing the calculations on existing inputs is common, resulting in
            >the need to change virtually every test.
            >
            >Any suggestions?
            >
            >

            I've never dealt with anything that complex, but a good chunk of my
            tests for complex algorithms isolate particular conditions, so that most
            of the variables are in some neutral setting that doesn't affect
            results. Then I have a relatively small number of tests that use all the
            variables together.

            When you add variable 138, how will you know what the right answer is
            when you create your tests?

            William
          • Keith Ray
            ... any of the 137 ... of the tests change If a test is an executable specification, then it should only be changing if the specification changes, regardless
            Message 5 of 8 , Dec 5, 2005
            • 0 Attachment
              On 12/5/05, Kenig, Neil <neil.kenig@...> wrote:

              >The problem is that a change in (calculation of the output due to)
              any of the 137
              >inputs necessarily changes the output for all of the inputs hence all
              of the tests change

              If a test is an executable specification, then it should only be
              changing if the specification changes, regardless of the number of
              inputs and outputs.

              If my JPEG implementation is composed of 10 classes, 100 methods
              total, changing one method might result in rendering every JPEG image
              decoded differently than before [for example, with a different gamma
              curve], but only a very few of my 300 unit tests would have to change,
              and very likely the acceptance tests would not change their
              implementations at all, just their "expected" image data files.

              --

              C. Keith Ray
              <http://homepage.mac.com/keithray/blog/index.html>
              <http://homepage.mac.com/keithray/xpminifaq.html>
              <http://homepage.mac.com/keithray/resume2.html>
            • Keith Ray
              first question: no I ll never have to change those unit tests again, so no maintenance. I m working from experience here, are you?
              Message 6 of 8 , Dec 5, 2005
              • 0 Attachment
                first question: no

                I'll never have to change those unit tests again, so no maintenance.

                I'm working from experience here, are you?


                On Dec 5, 2005, at 8:45 AM, Kenig, Neil wrote:

                > Did you have an Excel 'model' that mimicked the model in your
                > code? Is
                > that how you generated the 900 cases? If not, even though your unit
                > test was parameterized, changing the results means changing some
                > (most)
                > of the 900 cases; that's quite a bit of maintenance.
                >
                > Neil.
                >
                > -----Original Message-----
                > From: extremeprogramming@yahoogroups.com
                > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                > Sent: Monday, December 05, 2005 10:45 AM
                > To: extremeprogramming@yahoogroups.com
                > Cc: agile-testing@yahoogroups.com
                > Subject: Re: [XP] Test de-coupling
                >
                > Is the single output a single number, or is this a report-generation
                > program (or something like Excel)?
                >
                > The posting below talks about some filter functions I worked on
                > that had
                > about 7 inputs (not including the image itself), each inputs having
                > 2 to
                > 10 possible values, others having potentially infinite possible
                > values...
                >
                > <http://homepage.mac.com/keithray/blog/2005/09/28/>
                > "...Then I wrote 900 one-line unit tests to this parameterized unit
                > test
                > with the various permutations of the input parameters and expected
                > output values. (I actually worked in a spreadsheet for a while and
                > copied-pasted from the spreadsheet to the unit test source
                > code.) The test would also generate the output PDF file, which I could
                > visually examine...
                >
                >
                > On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:
                >
                >> Thanks for the recent responses on Excel testing. I was just reading
                >> Keith Ray's blog on testing
                >> http://homepage.mac.com/keithray/blog/2005/12/04/:
                >>
                >> "Fortunately for people doing incremental design work with
                >> refactoring, most automated tests do not have to change when the code
                >> is changed. The tests are acting as executable specifications for the
                >> requirements, so if the requirements haven't changed, then the tests
                >> should not have to change. Of course, when the tests are very
                >> close to
                >
                >> the implementation, they do sometimes need to be change, but the
                >> majority of tests should not change when someone need to alter the
                >> design to handle requirements being address in the current
                >> iteration."
                >>
                >> (This is an oversimplification but it makes the point.) We have an
                >> application that takes 137 inputs and produces a single output. We
                >> have tests that test the various inputs against the output. For
                >> example, one input may be a 5 choice selection - there will be tests
                >> to make sure that the output is correct for each of the five input
                >> choices. The problem is that a change in (calculation of the output
                >> due to) any of the 137 inputs necessarily changes the output for all
                >> of the inputs hence all of the tests change. Adding inputs (which
                >> change the
                >> result)
                >> and changing the calculations on existing inputs is common, resulting
                >> in the need to change virtually every test.
                >>
                >> Any suggestions?
                >>
                >> Neil Kenig
                >> PRICE Systems, L.L.C.
                >>
                >>
                >> Attention: PRICE Systems, L.L.C. maintains a safe computing
                >> environment but accepts no liability for any unintended effects
                >> arising from your receipt of data originating from PRICE Systems
                >> including this email and its attachments. Unintended effects
                >> include,
                >
                >> but are not limited to, loss of data or service due to harmful or
                >> malicious software such as computer viruses. Computer viruses can be
                >> transmitted via email. The recipient should check this email and any
                >> attachments for the presence of viruses. PRICE Systems accepts no
                >> liability for any damage caused by any virus transmitted by this
                >> email. E-mail transmission cannot be guaranteed to be secure or
                >> error-free as information could be intercepted, corrupted, lost,
                >> destroyed, arrive late or incomplete, or contain viruses. The sender
                >> therefore does not accept liability for any errors or omissions in
                >> the
                >
                >> contents of this message, which arise as a result of e-mail
                >> transmission.
                >>
                >>
                >>
                >> [Non-text portions of this message have been removed]
                >>
                >>
                >>
                >> 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 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 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
                >
                >
                >
                >
                >
                >
              • Kenig, Neil
                Yes, we currently have a suite of 13,000 Fitnesse assertions on our application. In thinking about the problem some more we have figured out a way to decouple
                Message 7 of 8 , Dec 6, 2005
                • 0 Attachment
                  Yes, we currently have a suite of 13,000 Fitnesse assertions on our
                  application. In thinking about the problem some more we have figured
                  out a way to decouple some of our tests by using a certain set of
                  inputs. As Stefan Steurs points out on the agile-testing list,
                  decoupling does make tests more like unit tests and makes them less
                  likely to find errors in interactions among features. An analogy might
                  be feeding an "all white" image into your system. Much of the
                  functionality can be exercised although much of the core processing
                  cannot.

                  -----Original Message-----
                  From: extremeprogramming@yahoogroups.com
                  [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                  Sent: Monday, December 05, 2005 10:59 PM
                  To: extremeprogramming@yahoogroups.com
                  Subject: Re: [XP] Test de-coupling

                  first question: no

                  I'll never have to change those unit tests again, so no maintenance.

                  I'm working from experience here, are you?


                  On Dec 5, 2005, at 8:45 AM, Kenig, Neil wrote:

                  > Did you have an Excel 'model' that mimicked the model in your code?
                  > Is that how you generated the 900 cases? If not, even though your
                  > unit test was parameterized, changing the results means changing some
                  > (most)
                  > of the 900 cases; that's quite a bit of maintenance.
                  >
                  > Neil.
                  >
                  > -----Original Message-----
                  > From: extremeprogramming@yahoogroups.com
                  > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                  > Sent: Monday, December 05, 2005 10:45 AM
                  > To: extremeprogramming@yahoogroups.com
                  > Cc: agile-testing@yahoogroups.com
                  > Subject: Re: [XP] Test de-coupling
                  >
                  > Is the single output a single number, or is this a report-generation
                  > program (or something like Excel)?
                  >
                  > The posting below talks about some filter functions I worked on that
                  > had about 7 inputs (not including the image itself), each inputs
                  > having
                  > 2 to
                  > 10 possible values, others having potentially infinite possible
                  > values...
                  >
                  > <http://homepage.mac.com/keithray/blog/2005/09/28/>
                  > "...Then I wrote 900 one-line unit tests to this parameterized unit
                  > test with the various permutations of the input parameters and
                  > expected output values. (I actually worked in a spreadsheet for a
                  > while and copied-pasted from the spreadsheet to the unit test source
                  > code.) The test would also generate the output PDF file, which I could

                  > visually examine...
                  >
                  >
                  > On Dec 5, 2005, at 6:48 AM, Kenig, Neil wrote:
                  >
                  >> Thanks for the recent responses on Excel testing. I was just reading

                  >> Keith Ray's blog on testing
                  >> http://homepage.mac.com/keithray/blog/2005/12/04/:
                  >>
                  >> "Fortunately for people doing incremental design work with
                  >> refactoring, most automated tests do not have to change when the code

                  >> is changed. The tests are acting as executable specifications for the

                  >> requirements, so if the requirements haven't changed, then the tests
                  >> should not have to change. Of course, when the tests are very close
                  >> to
                  >
                  >> the implementation, they do sometimes need to be change, but the
                  >> majority of tests should not change when someone need to alter the
                  >> design to handle requirements being address in the current
                  >> iteration."
                  >>
                  >> (This is an oversimplification but it makes the point.) We have an
                  >> application that takes 137 inputs and produces a single output. We
                  >> have tests that test the various inputs against the output. For
                  >> example, one input may be a 5 choice selection - there will be tests
                  >> to make sure that the output is correct for each of the five input
                  >> choices. The problem is that a change in (calculation of the output
                  >> due to) any of the 137 inputs necessarily changes the output for all
                  >> of the inputs hence all of the tests change. Adding inputs (which
                  >> change the
                  >> result)
                  >> and changing the calculations on existing inputs is common, resulting

                  >> in the need to change virtually every test.
                  >>
                  >> Any suggestions?
                  >>
                  >> Neil Kenig
                  >> PRICE Systems, L.L.C.
                  >>
                  >>
                  >> Attention: PRICE Systems, L.L.C. maintains a safe computing
                  >> environment but accepts no liability for any unintended effects
                  >> arising from your receipt of data originating from PRICE Systems
                  >> including this email and its attachments. Unintended effects
                  >> include,
                  >
                  >> but are not limited to, loss of data or service due to harmful or
                  >> malicious software such as computer viruses. Computer viruses can be
                  >> transmitted via email. The recipient should check this email and any
                  >> attachments for the presence of viruses. PRICE Systems accepts no
                  >> liability for any damage caused by any virus transmitted by this
                  >> email. E-mail transmission cannot be guaranteed to be secure or
                  >> error-free as information could be intercepted, corrupted, lost,
                  >> destroyed, arrive late or incomplete, or contain viruses. The sender
                  >> therefore does not accept liability for any errors or omissions in
                  >> the
                  >
                  >> contents of this message, which arise as a result of e-mail
                  >> transmission.
                  >>
                  >>
                  >>
                  >> [Non-text portions of this message have been removed]
                  >>
                  >>
                  >>
                  >> 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 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 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 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
                • Kenig, Neil
                  Well stated. This nature of coupling/de-coupling tests and designing/refactoring tests for speed/maintainability is one of the most difficult challenges that
                  Message 8 of 8 , Dec 6, 2005
                  • 0 Attachment
                    Well stated. This nature of coupling/de-coupling tests and
                    designing/refactoring tests for speed/maintainability is one of the most
                    difficult challenges that my organization currently faces in agile
                    development.

                    ________________________________

                    From: agile-testing@yahoogroups.com
                    [mailto:agile-testing@yahoogroups.com] On Behalf Of STEURS Stefan
                    Sent: Tuesday, December 06, 2005 4:31 AM
                    To: 'agile-testing@yahoogroups.com'
                    Cc: extremeprogramming@yahoogroups.com
                    Subject: RE: [agile-testing] Test de-coupling


                    I have also encountered many situations where a transversal change
                    affects many of the features/functions so tests have to be
                    modified/added over a wide range of objects/methods. It is easy to
                    state that change should be localised and affect only a few aspects of
                    the tests that have been automated without requiring a rewrite of the
                    tests.

                    The way I see it, a well structured set of tests is affected
                    proportionally to the changes in the code - from an over-all
                    perspective. This is only true when the tests are at the same level of
                    cohesion and dependency as the code. Abstract tests will be less
                    sensitive to changes but consequently will be less senstive to errors.

                    Localised changes are easy to deal with.

                    Take the following example: in release 1 the application provides
                    functions to provide CRUD on business objects. From release 2 onwards,
                    all business objects become versioned. The user can only affect the
                    present and future of an object but no longer the past. The change must
                    be implemented for all objects at the same time since the associations
                    that exist between them also have to be versioned.

                    A test to create data, retrieve data, update data, delete data, may
                    still continue to work as it was created initially but, since versioning
                    was not taken into account, cannot provide any evidence that versioning
                    actually works.

                    Tests may not be affected but if they are decoupled they provide no
                    evidence that feature interactions function as intended.

                    That is one of the major problems I keep encountering when I look at
                    automated tests. The tests isolate the feature to be tested but there
                    are too few tests that actually look at the interactions of these
                    features. True that such feature interaction tests are hard to design,
                    implement, and maintain, but most of the tough problems are also hiding
                    in the interactions (initial/intermediate state, order, timing,
                    multi-threading, etc).

                    For all that it's worth, tests are software and de-coupling of tests is
                    probably no different from de-coupling in the code. The tests have to
                    rely on a proper framework. But, this is only my own opinion and I
                    don't know enough, decoupling of tests should not become an obsession
                    and optimisation driven too far in the direction of decoupling will
                    trade-off with other qualities.

                    Regards, Stefan.

                    -----Original Message-----
                    From: agile-testing@yahoogroups.com
                    [mailto:agile-testing@yahoogroups.com]On Behalf Of Kenig, Neil
                    Sent: Monday, December 05, 2005 3:48 PM
                    To: agile-testing@yahoogroups.com
                    Cc: extremeprogramming@yahoogroups.com
                    Subject: [agile-testing] Test de-coupling


                    Thanks for the recent responses on Excel testing. I was just
                    reading Keith Ray's blog on testing
                    http://homepage.mac.com/keithray/blog/2005/12/04/:

                    "Fortunately for people doing incremental design work with
                    refactoring, most automated tests do not have to change when the code is
                    changed. The tests are acting as executable specifications for the
                    requirements, so if the requirements haven't changed, then the tests
                    should not have to change. Of course, when the tests are very close to
                    the implementation, they do sometimes need to be change, but the
                    majority of tests should not change when someone need to alter the
                    design to handle requirements being address in the current iteration."

                    (This is an oversimplification but it makes the point.) We have
                    an application that takes 137 inputs and produces a single output. We
                    have tests that test the various inputs against the output. For
                    example, one input may be a 5 choice selection - there will be tests to
                    make sure that the output is correct for each of the five input choices.
                    The problem is that a change in (calculation of the output due to) any
                    of the 137 inputs necessarily changes the output for all of the inputs
                    hence all of the tests change. Adding inputs (which change the result)
                    and changing the calculations on existing inputs is common, resulting in
                    the need to change virtually every test.

                    Any suggestions?

                    Neil Kenig
                    PRICE Systems, L.L.C.



                    <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
                    <<<<<<<<<<<<<<<<<

                    Attention: PRICE Systems, L.L.C. maintains a safe computing
                    environment but accepts no liability for any unintended effects arising
                    from your receipt of data originating from PRICE Systems including this
                    email and its attachments. Unintended effects include, but are not
                    limited to, loss of data or servic! e due to harmful or malicious
                    software such as computer viruses. Computer viruses can be transmitted
                    via email. The recipient should check this email and any attachments for
                    the presence of viruses. PRICE Systems accepts no liability for any
                    damage caused by any virus transmitted by this email. E-mail
                    transmission cannot be guaranteed to be secure or error-free as
                    information could be intercepted, corrupted, lost, destroyed, arrive
                    late or incomplete, or contain viruses. The sender therefore does not
                    accept liability for any errors or omissions in the contents of this
                    message, which arise as a result of e-mail transmission.



                    SPONSORED LINKS
                    Agile software development
                    <http://groups.yahoo.com/gads?t=ms&k=Agile+software+development&w1=Agile
                    +software+development&w2=Software+development+project+management&w3=Soft
                    ware+development+project+plan&w4=Acceptance+testing&c=4&s=140&.sig=pC2Cb
                    nCaCxN6ZXsti0jF1w> Software development project management
                    <http://groups.yahoo.com/gads?t=ms&k=Software+development+project+manage
                    ment&w1=Agile+software+development&w2=Software+development+project+manag
                    ement&w3=Software+development+project+plan&w4=Acceptance+testing&c=4&s=1
                    40&.sig=XgHMtgcekJphRllzaR6aTg> Software development project
                    plan
                    <http://groups.yahoo.com/gads?t=ms&k=Software+development+project+plan&w
                    1=Agile+software+development&w2=Software+development+project+management&
                    w3=Software+development+project+plan&w4=Acceptance+testing&c=4&s=140&.si
                    g=aQrjNeF6aY20fE1yGHeE0A>
                    Acceptance testing
                    <http://groups.yahoo.com/gads?t=ms&k=Acceptance+testing&w1=Agile+softwar
                    e+development&w2=Software+development+project+management&w3=Software+dev
                    elopment+project+plan&w4=Acceptance+testing&c=4&s=140&.sig=QTlO0GX7jnlD3
                    gwtcKedZw>

                    ________________________________

                    YAHOO! GROUPS LINKS



                    * Visit your group "agile-testing
                    <http://groups.yahoo.com/group/agile-testing> " on the web.

                    * To unsubscribe from this group, send an email to:
                    agile-testing-unsubscribe@yahoogroups.com
                    <mailto:agile-testing-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                    * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
                    Service <http://docs.yahoo.com/info/terms/> .


                    ________________________________


                    ____

                    This message and any files transmitted with it are legally privileged
                    and intended for the sole use of the individual(s) or entity to whom
                    they are addressed. If you are not the intended recipient, please notify
                    the sender by reply and delete the message and any attachments from your
                    system. Any unauthorised use or disclosure of the content of this
                    message is strictly prohibited and may be unlawful.

                    Nothing in this e-mail message amounts to a contractual or legal
                    commitment on the part of EUROCONTROL unless it is confirmed by
                    appropriately signed hard copy.

                    Any views expressed in this message are those of the sender.


                    [Non-text portions of this message have been removed]
                  Your message has been successfully submitted and would be delivered to recipients shortly.