how to write unit test
Maksim
I have read in books on xp the importance of well built unit tests.
There are few problems, though, that keep me from implementing them.
1)It's an imaging application and most of the code is already written,
and classes are implemented.
2)There is a lot of user input reqired.
3)Since it's an imaging app, a lot of what it's doing can be verfied
only visually (i.e. displaying a bitmap, rotationg it, annotation
etc.)
4)Document and view classes reference each other. That makes it
difficult to test them both.
If testing is such an important aspect, then I am sure there are ways
to implement unit tests even in imaging app (most of windows programms
have at least some of user interface), but I am not sure how to do it.
I have written fiew test(2-3), but these are to few to bring any kind
of significant benefit comparing to the time spent on them. I am a
little discouraged.
Any ideas or help would be appriciated.
Thank you.
P.S. I am using vc++ 6.0.
John Roth
"Maksim" <maksimp...@practiceworks.com> wrote in message
news:6befd713.01062...@posting.google.com...
> HI!
> I have read in books on xp the importance of well built unit tests.
> There are few problems, though, that keep me from implementing them.
>
> 1)It's an imaging application and most of the code is already written,
> and classes are implemented.
That's not a barrier, unless you need to refactor the methods to make
them testable. That's always a problem with trying to write good unit
tests for pre-existing code.
> 2)There is a lot of user input reqired.
That's always a problem. The way I've seen recommended is to
separate the UI from the processing as much as possible. Then you can
test the methods in the processing classes the same way you'd test any
other class. If you keep the UI classes minimal, then they won't change
very much, if at all, and manual testing is less painful.
It's possible to automate user interface testing, but how you do it
is totally dependent on the system and the UI package. I'd love to
have some tools with what I'm working with (Python and Tkinter at
the moment.)
> 3)Since it's an imaging app, a lot of what it's doing can be verfied
> only visually (i.e. displaying a bitmap, rotating it, annotation
> etc.)
Bitmaps exist in some kind of buffer, right? If your classes have methods
to manifest the buffer, then you can test the result of anything. I'd hate
to
write those tests - possibly automated capture on the "this looks good,
so I'll capture it," basis. At least, it makes a regression test possible.
On
the other hand, I'm certainly not a graphics specialist - there may be
real obvious ways of generating the expected results.
> 4)Document and view classes reference each other. That makes it
> difficult to test them both.
That makes it difficult (I'd say impossible) to test them in isolation.
However,
you usually can't test most classes in isolation anyway - if class "foo"
needs
an instance of class "bar" to function, then either you need to mock up a
dummy "bar", or use the real one. If you mock up a dummy, then what have
you tested? It's certainly not the real world.
Randy A. Ynchausti
> 1)It's an imaging application and most of the code is already written,
> and classes are implemented.
Unless you have the ability to go back and implement unit-tests for
everything (most people/projects don't), assume that all existing code works
and only implement unit-tests for new code, refactored code, and defect
fixes. This approach has been quite successful and has provided the best
value on a number of different projects and development platforms for me and
the people I work with.
> 2)There is a lot of user input reqired.
For the past year we have developed unit-testing approaches for user
interfaces. Basically, the "button-click" (gui element) action is invoked
by the unit-test which then makes sure that the appropriate results occur.
We assume that system testing will make sure that the right actions occur
when the user presses the gui button.
> 3)Since it's an imaging app, a lot of what it's doing can be verfied
> only visually (i.e. displaying a bitmap, rotationg it, annotation
> etc.)
Try looking at a unit-test as verifying that an individual method works
correctly. We are always amazed at how simple unit-testing becomes when you
are making sure that a method works correctly. Otherwise, you might find it
useful to generate some known input images with associates expected rotated
images for comparison in the unit-tests.
> 4)Document and view classes reference each other. That makes it
> difficult to test them both.
We have found it much easier to thing about testing methods in classes,
rather than testing classes. If your unit-tests prove that every method in
a class works, then it is not a far leap to assume that the class works
properly. This approach seems to make unit-testing much easier for most
developers.
> If testing is such an important aspect, then I am sure there are ways
> to implement unit tests even in imaging app (most of windows programms
> have at least some of user interface), but I am not sure how to do it.
Start one method at a time.
> I have written fiew test(2-3), but these are to few to bring any kind
> of significant benefit comparing to the time spent on them. I am a
> little discouraged.
You will likely be more discouraged when you provide a application to user
and they find defects that unit-tests could have prevented.
Regards,
Randy
Maksim
Thanks for the ideas.
What's a "regression test"?
David Buck
Maksim wrote:
> <snip>
> What's a "regression test"?
A regression test is a test to make sure you didn't go backward - i.e., a regression test tests that
everything that used to work before still works now (as opposed to tests of new functionality).
David Buck
Simberon Inc.
Darryl Palmer
to keep the speed of your integration tests down. I am not saying that you
shouldn't test bar at all, but you could maybe test "bar" by itself and then
test "foo" with a dummy bar because it has been tested in other test cases.
Darryl Palmer
"John Roth" <john...@ameritech.net> wrote in message
news:tj4ksbc...@news.supernews.com...
John Roth
"Darryl Palmer" <darryl...@worldnet.att.net> wrote in message
news:vKcZ6.5229$kx3.5...@bgtnsc06-news.ops.worldnet.att.net...
> It is hard to make a blanket statement like this, sometimes you need a
dummy
> to keep the speed of your integration tests down. I am not saying that
you
> shouldn't test bar at all, but you could maybe test "bar" by itself and
then
> test "foo" with a dummy bar because it has been tested in other test
cases.
>
> Darryl Palmer
It's actually easy to make blanket statements - especially when you realize
that every blanket statement has exceptions. Some of the common exceptions
to this one are data base access, access to restricted, privaleged or
expensive
resources, coordinating projects that aren't quite there yet, and GUI
interface
classes.
The basic lesson is, I suspect, that general statements are there for a
reason,
so the exception has to make sense. In other words, work at eliminating the
exception until you know why you can't, and what it's going to cost you.
If the reason for using a testing dummy is simply the (lack of) performance
of the unit test suite, then I would suggest a faster machine. In the long
term,
it's likely to be much less expensive than the work required to maintain
test
harnesses. Like anything else, it's a resource tradeoff.
John Roth