How can I unit test a GUI?

Question

The calculations in my code are well-tested, but because there is so much GUI code, my overall code coverage is lower than I\'d like. Are there any guidelines on unit-testin

Answer 1

If you are using Swing, FEST-Swing is useful for driving your GUI and testing assertions. It makes it pretty straightforward to test things like "if I click button A, dialog B should be displayed" or "if I select option 2 from the drop-down, all the checkboxes should become deselected".

The graph scenario that you mention is not so easy to test. It's pretty easy to get code coverage for GUI components just by creating and displaying them (and perhaps driving them with FEST). However, making meaningful assertions is the hard part (and code coverage without meaningful assertions is an exercise in self-deception). How do you test that the graph was not drawn upside-down, or too small?

I think that you just have to accept that some aspects of GUIs cannot be tested effectively by automated unit tests and that you will have to test them in other ways.

Answer 2

From what I know, this is quite complicated, and really depends on the language - numerous languages have their own way of testing GUI, but if you really need to test the GUI (as opposed to model/gui interaction), you often have to simulate an actual user clicking buttons. For example, the SWT framework used in Eclipse provides SWTBot, JFCUnit has already been mentioned, Mozilla has their own way of simulating this in XUL (and from what I've read on their blogs, these tests seem to be quite brittle).

Sometimes you have to take a screenshot, and test for pixel-perfect rendering (I believe that Mozilla does this to check for correctly rendered pages) - this requires a lengthier setup, but might be what you need for the graphs. That way, when you update your code and a test breaks, you have to manually check the image if the failure was real, or you improved the graph rendering code to generate prettier graphs and need to update the screenshots.

Answer 3

You can try UISpec4J is an Open Source functional and/or unit testing library for Swing-based Java applications...

Answer 4

Here is some tips:

Try to remove the most code you can from the GUI (have controller, and model object) this way you will be able to test them without the GUI.

For the graphic, you should test the value that you supply to the code that generate the graphic.

Answer 5

Testing is an art form. I agree the logic should be removed GUI as much as possible. We can then focus our unit testing there. Like anything else testing is about reducing risk. You dont always need to test everything but alot of times the best thing is to break the different testing up for at different areas.

The other question is what are you really trying to test at the UI layer. UI testing is the most expensive testing because it usually takes longer to create, maintain and it is the most brittle. If you test the logic to know the coordinates are correct prior to trying to draw the line what are you testing specifically? If you want to test a graph with a red line is drawn. Can you give it a set predetermined coordinates and test if certain pixels are red or not red? As suggested above bitmap comparisons work, Selenium but my main focus would be not to over test the GUI but rather test the logic that will help create the UI and then focus on what portion of the UI breaks or is suspect and focus a handful of tests there.

Answer 6

You can try to use Cucumber and Swinger for writing functional acceptance tests in plain english for Swing GUI applications. Swinger uses Netbeans' Jemmy library under the hood to drive the app.

Cucumber allows you to write tests like this:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Take a look at this Swinger video demo to see it in action.