News »Browse Articles » Asynchronous testing of swing applications

I`m telling you about some experiences I had with specific issues when testing Swing applications (it happened with the blueMarine development, but this article is focused on Swing and not on the NetBeans Platform). I`d like to hear your opinion about a solution I`ve found and, before I code more on it, whether you know an existing framework that works in a similar way.

As many have said many times, testing is one of the most important activities for the success of a project. This is probably even more true for desktop applications than regular web applications, since they have more sophisticated behaviours and interactivity with the user. Indeed, many Web 2.0 applications are getting rich in interactivity too, but most of them don`t have sophisticated asynchronous models, either for limitations of the technology or because they are made simple on purpose. After all the Web is still modelled on network transactions, even if you`re using AJAX; this means that you still have plenty of probing points for integration testing using the communicating channel between the client and the server.

Consider instead a Swing-based desktop application with the following behaviour:

1. you have a file system explorer and you select folders
2. upon each selection, the application scans the folders (potentially in a recursive fashion) for searching contained media
3. when the selection has been completed, some thumbnails appear in a viewer.

Of course, this must be done with background threads, so the application is responsive, that is the user is able to keep on selecting other folders while the previous scan is not completed yet; in this case, the still-running thread is cancelled.

Now, let`s suppose we want to write a high-level integration test for this scenario. The probing point is just the user interface: you perform a selection and want to assert that "some time later" another part of the UI has been updated. We could think of this test code sketch:
view source
print?
01.package it.tidalwave.bluemarine.filesystemexplorer.test;
02.
03.public class FolderSelectionTest extends AutomatedTest
04. {
05. private static final int THUMBNAIL_SELECTION_TIMEOUT = 4000;
06.
07. private FileSystemExplorerTestHelper f;
08. private ThumbnailViewerTestHelper t;
09.
10. ...
11.
12. @Before
13. public void prepare()
14. {
15. f = new FileSystemExplorerTestHelper();
16. t = new ThumbnailViewerTestHelper();
17. }
18.
19. @After
20. public void shutDown()
21. {
22. f.dispose();
23. t.dispose();
24. }
25.
26. @Test
27. public void run()
28. throws Exception
29. {
30. activate(f.fileSystemExplorerTopComponent);
31. f.resetSelection();
32.
33. selectNode(f.upperExplorer, f.view.findUpperNodeByPath(BaseTestSet.getPath()));
34. select(f.cbSubfolders, true);
35. // WAIT FOR THE COMPUTATION TO COMPLETE
36.
37. assertActivated(f.fileSystemExplorerTopComponent.getClass().getName());
38. assertOpened(t.thumbnailViewerTopComponent.getClass().getName());
39. ThumbnailViewerTestHelper.assertShownFiles(t.thumbnailListView, BaseTestSet.getPath(), BaseTestSet.getAllFiles());
40. ...
41. }
42.
43. ...
44. }

This is actually real code from blueMarine`s tests, and I think it`s pretty readable (at least if you know a bit of basic concepts of the NetBeans Platform). It activates a TopComponent, resets the folder selection, selects a node in an explorer, selects a checkbox (cbSubfolders is a checkbox that enables recursive scanning), and asserts that the TopComponent for selecting files is still active (= it has got the focus), the thumbnail viewer TopComponent is opened and its view is populated with all the files of the test set. The TestHelpers are facility classes that cooperate with some parts of the UI classes, offering references that point to the relevant UI components and specific assertion methods.

The various methods in the test body are statically imported from an utility class and perform the proper UI manipulation in the EDT thread - this is a common solution of many Swing-related testing frameworks.

blueMarine at the moment doesn`t use any of the existing, such as Abbot and Costello or Jemmy / Jelly. This is for historical reasons (initial tests were written quite a few years ago, before the conversion to NetBeans, even though most of them has been "lost" in the conversion) and they will eventually converge to the standard framework used by NetBeans. But this is not relevant with the problem I`m talking about.

Source:
http://java.dzone.com/news/testing-tales-about

No Comments For This News

Post a link to something interesting from another site, or submit your own original writing for the Java community to read.