views:

171

answers:

5

I'm learning JUnit. Since my app includes graphical output, I want the ability to eyeball the output and manually pass or fail the test based on what I see. It should wait for me for a while, then fail if it times out.

Is there a way to do this within JUnit (or its extensions), or should I just throw up a dialog box and assertTrue on the output? It seems like it might be a common problem with an existing solution.

Edit: If I shouldn't be using JUnit for this, what should I be using? I want to manually verify the build every so often, and unit test automatically, and it'd be great if the two testing frameworks got along.

+6  A: 

Manually accepting/rejecting a test defeats the purpose of using an automated test framework. JUnit is not made for this kind of stuff. Unless you find a way to create and inject a mockup of the object representing your output device, you should consider alternatives (don't really know any there sorry).

I once wrote automated tests for a video decoding component. I dumped the decoded data to a file using some other decoder as a reference, and then compared the output of my decoder to that using the PSNR of each pair of images. This is not 100% self contained (needs external files as resources), but was automated at least, and worked fine for me.

Space_C0wb0y
I'll look into a way to automatically eyeball the output. Not ideal, might work for obvious regressions.
Alex Feinman
+1  A: 

Unit tests shouldn't require human intervention. If you need a user to take an action then I think you're doing it wrong.

If you need a human to verify things, then don't do this as part of your unit tests. Just make it a required step for your test department to carry out when QA'ing builds. (this still works of your QA department is just you.)

Glen
+3  A: 

Although you could probably code that, that is not what JUnit is about. It is about automated tests, not guided manual tests. Generally that "does it look right" test is regarded as an integration test, as it is something that is very hard to automate correctly in a way that doesn't break for trivial changes all the time.

Take a look at Abbot to give you a more robust way to test your GUI.

Yishai
Or FEST (http://code.google.com/p/fest/).
Dan Dyer
It's not the GUI I want to test; it's graphical output. Thanks for the pointers for when I *do* get to testing the GUI, though!
Alex Feinman
A: 

I recommend using your unit tests for the Models if using MVC, or any utility method (i.e. with Swing it's common to have color mapping methods). If you have a good set of unit tests on things like model behavior, if you have a UI bug it'll help narrow your search.

Visual based unit tests are very difficult, at a company I worked at they had tried these visual tests but slight differences in video cards could produce failed tests. In the end this is where a good Q/A team is required.

reccles
A: 

Take a look at FEST-Swing. It provides an easy way to automatically test your GUIs.

The other thing you'll want to do is separate your the code which does the bulk of the work from your gui code as much as possible. You can then write unit tests on this work code without having to deal with the user interface. You'll also find that you'll run these tests much more frequently, as they can run quickly.

deterb