In a previous article I began to describe how you can set up a test frame using JUnit and Jemmy that could easily be extended as and when you require new tests. In this article we will cover running tests on both JavaFX and Swing as well as only other systems and introduce an example test for our PDF library JPedal.
Before I begin I need to make a correction to my previous article. In order to get a snapshot of the application I gave the following code as an example. Whilst this works it is likely to show differences when comparing against your baseline unless it is executed from the Event Thread.
Handling Other Systems
This is actually relatively simple considering Java has a simple static method that can get you the name of the OS you are currently using. This method looks something like this System.getProperty(“os.name”);. To determine between operating systems you just need to check the string that this method returns for one of the following.
For Windows : The String must start with the string “Windows”
For Mac OSX : The string should equal “Mac OS X”
For Mac OSX : The string should contain”OS X” (Thanks to Will for noticing this.)
For Linux : The string should equal “Linux”
My advice would be to have a flag or flags that can be used to determine the OS you are using as you may need this more than once later on. Once you have a flag you simply copy the 3 variables created last time into if statements so they are created with paths correct for the OS.
Running tests on both JavaFX and Swing
When writing the first article I had plans on how to complete a system that would allow for tests to be written for both tool kits. Since then I have found a better way. What we are to do is copy BaseClass.java from my previous article and rename these two files to BaseClassSwing.java and BaseClassJavaFX.java. Now you will need to convert any Swing code to JavaFX code in the JavaFX version.
Now when developing a test you should only need to write the code to open the application (ensuring you have extended the correct base class) and call the methods to perform whatever actions the tests require. The base classes will only need code adding to handle new types of tests that have a different type of output and also require a new way to compare that output.
Writing An Example Test
So now that we have something that should work I will give a breakdown of a small Jemmy test using our PDF library JPedal. This test is designed to open our Swing viewer with a specified file, highlight all text on the page, take a screen shot, then compare it against a baseline. Note that this example explains how to perform the test and get the output, you will need to handle image comparison with your own code.
First we need to decide which base class we need and have the test open the application to be tested. In this case we are testing the Swing Viewer so we will be extending the Swing base class. In order to open the Swing Viewer we use the following methods.
ClassReference opens the application using the classpath for the class that will start the application. The application only runs once startApplication has been called with the string array being arguments for the application. In this case we are passing in the file name of the file to be opened by the viewer.
Now that we have the application open I want to be able to pass input to the application as a user might. I also want to maximise the viewer so we have a larger output snapshot thus allowing smaller changes in functionality to be more noticeable. This can be done with the following two lines. The first gets the frame of the viewer and the second maximises it.
In the lines above you will notice that the JFrameOperator allows us to access the actual JFrame by calling the method getSource(). This is the same for the various operators used in Jemmy.
Next we need to highlight all the text on the page using the keyboard command CTRL+A and then take a snapshot of the viewer with the text highlighted. When doing this I recommend having the Thread wait a short time to ensure all functionality is complete before you attempt to continue beyond certain points as shown below.
Here we wait after highlighting test to ensure it is complete and after taking the snapshot to ensure its completion as well. The output name for the snapshot is the same as the pdf name except instead of ending ‘.pdf’ it ends ‘.png’.
Finally we need to exit the test which is done by simply using the Exit option from the menu bar.
Below are the three classes created so far. The classes are incomplete – they require the compare method in the base class.
In my next article I will cover some ideas and practices that I have found useful in testing to ensure we avoid the possibility of issues slipping through our existing tests. See you then.
Hopefully you have found this useful.