Test driven design and graphics in Java

Thread view:

Kenneth P. Turvey - 10 Apr 2008 18:41 GMT

I'm currently writing some code using swing that works on images. This
is all fine, and no problem, but my method for testing it is bugging me a
bit.

The only way I can really see to test the graphics drawing components is
with a mock Graphics2D object that keeps track of the method calls. I
then check to make sure that the code makes the correct calls.

This works, but it seems awfully brittle. In addition the code for
implementing the test and the code being tested often look quite
similar. This really isn't ideal.

Is there a better way to handle this problem? Does anyone out there have
any suggestions?

Thanks.

Signature

Kenneth P. Turvey <kt-usenet@squeakydolphin.com>

Reply to this Message

Kenneth P. Turvey - 18 Apr 2008 08:01 GMT

> I'm currently writing some code using swing that works on images. This
> is all fine, and no problem, but my method for testing it is bugging me
[quoted text clipped - 10 lines]
> Is there a better way to handle this problem? Does anyone out there
> have any suggestions?

Nobody using Java to do graphical work? I know this is a hard problem,
much like testing GUIs... I also know that the answer for GUIs is often
"don't test the view". This seems like a real deficiency to me. Any
suggestions or comments?

Signature

Kenneth P. Turvey <kt-usenet@squeakydolphin.com>

Reply to this Message

Andrea Francia - 18 Apr 2008 08:51 GMT

> Nobody using Java to do graphical work? I know this is a hard problem,
> much like testing GUIs... I also know that the answer for GUIs is often
> "don't test the view".

Actually the GUIs can be tested. I use the fest-swing framework that
simulate the user inputs and check the graphical result.

Signature

Andrea Francia
http://www.andreafrancia.it/

Reply to this Message

Andrea Francia - 18 Apr 2008 08:55 GMT

> I also know that the answer for GUIs is often "don't test the view".

This is a bad advice. Every requirements of the software should be
tested, also those that are difficult to test in automatically.

When you can test automatically a feature you should test it manually.

Signature

Andrea Francia
http://www.andreafrancia.it/

Reply to this Message

Kenneth P. Turvey - 18 Apr 2008 19:26 GMT

>> I also know that the answer for GUIs is often "don't test the view".
> This is a bad advice. Every requirements of the software should be
> tested, also those that are difficult to test in automatically.
>
> When you can test automatically a feature you should test it manually.

That's really what I meant.. no automated test. I guess that's where I
am right now. Some of my tests are going to have to be manual tests.

Signature

Kenneth P. Turvey <kt-usenet@squeakydolphin.com>

Reply to this Message

Daniel Pitts - 18 Apr 2008 21:37 GMT

>>> I also know that the answer for GUIs is often "don't test the view".
>> This is a bad advice. Every requirements of the software should be
[quoted text clipped - 4 lines]
> That's really what I meant.. no automated test. I guess that's where I
> am right now. Some of my tests are going to have to be manual tests.

With "Test Driven Development", you write the a test first, and then
write the minimum amount of code to make it succeed.

This is NOT a testing methodology. Proper testing needs to find all edge
cases and problems. TDD is used to ensure that certain features work as
you expect them to, without interfering with other preexisting features.

This is indeed difficult for GUI/Graphical interfaces. I found the best
I could do is just assume that GUI interface is a one-to-one call into
the controller/model API, and testing *that* interface should be "good
enough".

In other words, don't test "User Clicks Button". test "Event Fired When
User Clicks Button"

Signature

Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Reply to this Message

Kenneth P. Turvey - 18 Apr 2008 23:05 GMT

[Snip]

> In other words, don't test "User Clicks Button". test "Event Fired When
> User Clicks Button"

[Snip]

I understand all this, but I'm really working on a graphical
application. The problem isn't really to test whether a single event is
fired. The problem is to determine if an image has been altered
correctly when a certain sequence of events happen... or something
similar.

I was using the methodology you recommend, testing to see if the event
was fired, or the equivalent, checking to see if the correct calls to the
graphics object were made, but this turned into a nightmare. Small
changes to the code lead to great changes to the calls to the Graphics
object. So the testing is very brittle.

I think the best I can do is provide before and after images and see if
the tests produce what is expected. Unfortunately, this really means
that the tests cannot be developed before the code is written since the
code must be used to do the image processing. This will probably still
work for future changes, to make sure that I'm not breaking code, but it
won't help for directing development.

Signature

Kenneth P. Turvey <kt-usenet@squeakydolphin.com>

Reply to this Message

Mark Space - 19 Apr 2008 00:44 GMT

> I understand all this, but I'm really working on a graphical
> application. The problem isn't really to test whether a single event is
> fired. The problem is to determine if an image has been altered
> correctly when a certain sequence of events happen... or something
> similar.

I may not be understanding correctly here, but the first thing that
occurs to me is to yoink the methods that perform these graphical
calculations out of the view, and place them in a separate class that
can be tested easily. Get rid of the Graphic2D object and other Swing
objects (although you might have to keep Image).

Then once that class is unit tested, it becomes a matter of integration
testing when you compose the view with a real graphics object, but that
can be done much more coarsely.

I think is see what you mean by "test is similar the method being
tested." To test if a method makes an Image 50% darker, you need an
image that's 50% darker to test against. Hmmm, not sure there's a way
around that....

You might want to be concerned with things like boundary conditions
(memory, pointers, indexing) in the unit test and use some other method
for the calculations themselves. Code review + mathematical proof perhaps?

Reply to this Message

Lew - 19 Apr 2008 04:02 GMT

> I think is see what you mean by "test is similar the method being
> tested." To test if a method makes an Image 50% darker, you need an
> image that's 50% darker to test against. Hmmm, not sure there's a way
> around that....

What does "50% darker" mean, hmm? Some guy looks at it and says, "Yup, that's
50%!" Then his brother says, "No, it ain't!" Then Aunt Tilly says, "Why is
that picture so dark? Sonny, turn up the brightness, will you?"

How do you know if you've made the picture darker, let alone 50%? Dollars to
donuts it's via a testable condition, such as, oh, given a certain HSB value,
the new B is half the old value. Then you devise a test that fires the
trigger you expect the "darken 50%" button to fire, and compare the resultant
image's (average) B to the original value, and see if it's half.
Automatically. Then all you have to test the GUI for is that it fires the
correct event, not even connect that test to images at all.

Signature

Lew

Reply to this Message

Andrea Francia - 18 Apr 2008 08:49 GMT

> I'm currently writing some code using swing that works on images. This
> is all fine, and no problem, but my method for testing it is bugging me a
[quoted text clipped - 10 lines]
> Is there a better way to handle this problem? Does anyone out there have
> any suggestions?

Test the result, not the implementation.

Signature

Andrea Francia
http://www.andreafrancia.it/

Reply to this Message

Test driven design and graphics in Java

Free Magazines