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

Testing Examples

Expand Messages
  • David Brady
    Has anyone here had success with writing a test, and had someone come along later and actually break the thing and get caught by the test? All the tests I can
    Message 1 of 5 , Apr 3, 2000
    • 0 Attachment
      Has anyone here had success with writing a test, and had someone come along
      later and actually break the thing and get caught by the test? All the
      tests I can think of are ones that if they pass once, the code will never
      break again.

      Last week, I fixed a bug in a program's floating point to 16:16 fixed-point
      converter, that arose from a programmer dividing/multiplying by a hardcoded
      65535 (0xFFFF) instead of the correct 65536 (0x10000). I wrote a test that
      takes a number, converts it, and then checks the results to see if they are
      correct. This test will never break again, unless another programmer comes
      along and deliberately changes the hardcoded conversion constant, which is
      unlikely in the extreme. Writing the test seems to me to have been a waste
      of time.

      Because of this, I get the feeling that I'm thinking about tests in the
      wrong way. What are the things I should be testing for? How are they
      likely to break in the future?

      If someone has a good grasp on the right kinds of tests to write, and maybe
      an example or two, could you post it here?

      Thanks,

      -dB
      --
      David Brady
      dbrady@...
      Diagonally parked in a parallel universe
    • Chris Berry
      ... History, in programming as in all things, has an incredible way of repeating itself. Cheers, -- Chris
      Message 2 of 5 , Apr 3, 2000
      • 0 Attachment
        > -----Original Message-----
        > From: David Brady [mailto:dbrady@...]
        > Sent: Monday, April 03, 2000 9:32 AM
        > To: 'extremeprogramming@egroups.com'
        > Subject: [XP] Testing Examples
        >
        >
        > Has anyone here had success with writing a test, and had someone
        > come along
        > later and actually break the thing and get caught by the test? All the
        > tests I can think of are ones that if they pass once, the code will never
        > break again.
        >

        History, in programming as in all things, has an incredible way of repeating
        itself.
        Cheers,
        -- Chris
      • Andy Glew
        ... Do you use a version control system like CVS or SourceSafe? Do you ever back out a whole slew of changes, and go back to an earlier version? Or, is it
        Message 3 of 5 , Apr 3, 2000
        • 0 Attachment
          > Last week, I fixed a bug in a program's floating point to 16:16 fixed-point
          > converter, that arose from a programmer dividing/multiplying by a hardcoded
          > 65535 (0xFFFF) instead of the correct 65536 (0x10000). I wrote a test that
          > takes a number, converts it, and then checks the results to see if they are
          > correct. This test will never break again, unless another programmer comes
          > along and deliberately changes the hardcoded conversion constant, which is
          > unlikely in the extreme. Writing the test seems to me to have been a waste
          > of time.

          Do you use a version control system like CVS or SourceSafe?
          Do you ever back out a whole slew of changes, and go back to an earlier version?

          Or, is it possible that somebody - another programmer, a customer, whatever -
          may send in a bugfix for some other bug, that happened to include the
          divide by 65535 vs. 65536 code?

          Or is it possible that somebody, someday, fixing a different bug
          may do a global edit changing 2^16 into 2^16-1?

          In any of these cases, it is possible that the old bug may be reproduced.
          What you have written is a regression test.

          ---

          Actually, this post tickled a memory. I used to work on machines with
          software floating point, rather than hardware. One of them had a bug
          in the divide code. The bug occurred near the 2^16 boundary.

          I.e. this regression test may save you if you go to a new machine
          and/or upgrade your floating point library.
        • Ron Jeffries
          ... Happens all the time in classes that are more actively changing than the numeric converters, but in fact I ve seen tests there fail when someone goes to
          Message 4 of 5 , Apr 3, 2000
          • 0 Attachment
            At 08:31 AM 4/3/2000 -0600, you wrote:
            >Has anyone here had success with writing a test, and had someone come along
            >later and actually break the thing and get caught by the test? All the
            >tests I can think of are ones that if they pass once, the code will never
            >break again.

            Happens all the time in classes that are more actively changing than the
            numeric converters, but in fact I've seen tests there fail when someone
            goes to add some capability to the conversions.

            >Last week, I fixed a bug in a program's floating point to 16:16 fixed-point
            >converter, that arose from a programmer dividing/multiplying by a hardcoded
            >65535 (0xFFFF) instead of the correct 65536 (0x10000). I wrote a test that
            >takes a number, converts it, and then checks the results to see if they are
            >correct. This test will never break again, unless another programmer comes
            >along and deliberately changes the hardcoded conversion constant, which is
            >unlikely in the extreme. Writing the test seems to me to have been a waste
            >of time.

            It may have been, as changing the code so as to break it seems unlikely.
            But the test does no harm as written, _might_ catch something, was probably
            a good way to check to see if you had the answer right, and in general such
            tests are more likely useful in the future. Each one is a brick in the
            wall. You need the whole wall, so you write each brick.

            >Because of this, I get the feeling that I'm thinking about tests in the
            >wrong way. What are the things I should be testing for? How are they
            >likely to break in the future?

            How about if you send us a few of your tests, or descriptions of them, for
            more volatile classes in the system. We'll see what we can say.

            Ron Jeffries
            www.XProgramming.com
          • Trushkin, Vladimir
            As I ve read in one of smart books: There are too many chances to fail while thinking about what is suitable to be tested and what is not that you better be
            Message 5 of 5 , Apr 4, 2000
            • 0 Attachment
              As I've read in one of 'smart' books:

              There are too many chances to fail while thinking about what is suitable to
              be tested and what is not that you better be off it and just write several
              cheap tests.

              It's better to just mock up several tests quickly that will cover a
              questionable part of your system than to think out whether it is suitable to
              be tested or not. There are too many variables that the decision depends on,
              so, it is considered much more cheaper to write tests for it and to obtain
              100% feasible coverage.

              Best Wishes,
              Vladimir

              -----Original Message-----
              From: David Brady [mailto:dbrady@...]
              Sent: Monday, April 03, 2000 5:32 PM
              To: 'extremeprogramming@egroups.com'
              Subject: [XP] Testing Examples


              Has anyone here had success with writing a test, and had someone come along
              later and actually break the thing and get caught by the test? All the
              tests I can think of are ones that if they pass once, the code will never
              break again.

              Last week, I fixed a bug in a program's floating point to 16:16 fixed-point
              converter, that arose from a programmer dividing/multiplying by a hardcoded
              65535 (0xFFFF) instead of the correct 65536 (0x10000). I wrote a test that
              takes a number, converts it, and then checks the results to see if they are
              correct. This test will never break again, unless another programmer comes
              along and deliberately changes the hardcoded conversion constant, which is
              unlikely in the extreme. Writing the test seems to me to have been a waste
              of time.

              Because of this, I get the feeling that I'm thinking about tests in the
              wrong way. What are the things I should be testing for? How are they
              likely to break in the future?

              If someone has a good grasp on the right kinds of tests to write, and maybe
              an example or two, could you post it here?

              Thanks,

              -dB
              --
              David Brady
              dbrady@...
              Diagonally parked in a parallel universe


              To Post a message, send it to: extremeprogramming@...

              To Unsubscribe, send a blank message to:
              extremeprogramming-unsubscribe@...

              Ad-free courtesy of objectmentor.com
            Your message has been successfully submitted and would be delivered to recipients shortly.