Re: lots of quick tests that have very low cost but uncertain value
- From: Phlip <phlip2005@xxxxxxxxx>
- Date: Tue, 07 Mar 2006 21:40:08 GMT
Michael Bolton wrote:
In answer to your descripition of "inaccurate tests". I don't know
what you mean by inaccurate tests, so you can define them as you like.
:) Do you mean "useless tests"? Tests that are based on erroneous
presumptions? Tests that ignore things like system requirements?
Tests that could not conceivably matter to anyone? Tests that do not
address some risk? Such tests can exist, but I don't think I would
call these "inaccurate"; perhaps "inappropriate" or "unhelpful" or
"(probably) valueless". But you may have something else in mind.
Suppose I write a complex GUI, such as a web browser.
The lowest level of such a system is a Paint() event (a WM_PAINT in Windows,
a Paint(Graphics g) in Java, etc.).
The Paint() event always passes to the programmer a reference to a graphics
device context. This behaves kind of like MsPaint, with a toolbar of
brushes and colors, and a raster. A complex Paint() event handler will pick
a brush, and draw a sequence of colored strokes on the raster.
Suppose I write a Paint() event that paints Red over here, and Green over
there.
To unit test this, create a mock graphics device context. Some systems
expose a "metafile" system, to spool graphic commands for later replay.
Some systems let you create a mock object out of the Graphics object. I
think Google will return hits for "mock graphics" here.
Unit tests now set up the web browser, call the Paint() event, and collect a
big long string or list of canned graphical commands. All intercepted from
going into a real raster.
A cheap test on such a string (a "log string test") doesn't need to
reconstitute the raster and "look at it". The test could trivially check
the list contains a Red stroke, some more operations, and then a Green
stroke.
Now suppose we perform a clean, dainty refactor on our code. It still paints
Red, then Green, and the test passes.
Now suppose we perform a sloppy refactor, or we add a feature. We twiddle
the code, maybe move a calling function, and now the Paint() event paints
the Green stroke first, then the Red stroke.
If the strokes were supposed to overlap, the user would now perceive a bug.
If they don't, then the user doesn't care what order the strokes go. (Maybe
the system uses masks and stencils, so the stroke order is less relevant.)
As programmers (and testers), keeping the tests cheap is more important than
making them perfect. The test should not pass _any_ Red and _any_ Green,
because this is easier to break in a bigger way. The test _cannot_ render
an entire raster and look at it, because AI is klutzy enough for production
code without burdening test code with it too.
The tests should force us to back out our change and try again - _even_ if
the change itself caused no real bug.
(Those of you seething about over the TDD references should be assured that
these situations matter at all scales, including the acceptance tests.)
So Achilles leaps over the turtle and declares where it will stop. The
turtle stops there, and a higher level of testing is achieved.
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
.
- Follow-Ups:
- Re: lots of quick tests that have very low cost but uncertain value
- From: Michael Bolton
- Re: lots of quick tests that have very low cost but uncertain value
- References:
- lots of quick tests that have very low cost but uncertain value
- From: Phlip
- Re: lots of quick tests that have very low cost but uncertain value
- From: Llarry
- Re: lots of quick tests that have very low cost but uncertain value
- From: Phlip
- Re: lots of quick tests that have very low cost but uncertain value
- From: Shrinik
- Re: lots of quick tests that have very low cost but uncertain value
- From: Phlip
- Re: lots of quick tests that have very low cost but uncertain value
- From: Michael Bolton
- lots of quick tests that have very low cost but uncertain value
- Prev by Date: Re: lots of quick tests that have very low cost but uncertain value
- Next by Date: Re: help needed in Cadence SMV
- Previous by thread: Re: lots of quick tests that have very low cost but uncertain value
- Next by thread: Re: lots of quick tests that have very low cost but uncertain value
- Index(es):
Relevant Pages
|