Created On:  14 September 2010
Creating ‘Tags’ In Silk4J
Introduction
The problem with the SilkTest Recorder is that captures only the raw locator strings and does not create tags in the sense that those familiar with the Classic Agent know about. Java does not support header files in the sense that C or C++ programmers are familiar with, so that path is not an option. As it turns out, there are three solutions to this problem and which one you chose is dependant upon company practice and to a certain extent, project size and the requirement for code portability.
The first is to do nothing and live with the raw locator strings. For a single small record-and-playback testcase this would not a problem. To a degree, even adding some verification and logging statements is not going to destroy the script readability. However, as the script gets longer readability will start to suffer and when you get to writing scripts, the approach of using raw locator strings for tagging gets very clumsy and time consuming.
The second option is to place the locator strings into easily-remembered string variable names. This will improve both script construction and readability and removes the necessity to remember the names of . These strings variables can be local to the testcase or can be global to the project’s test class. Making them global makes them available for all test scripts in that class. The limitation of this approach is that it is not very good for large solutions as it would entail a lot of copying and pasting into new projects.
For large solutions and for portability between solutions the best approach is the class library. This keeps all of the tags for a given application in a single jarfile and makes them globally available for all solutions. Any changes made to the class library will automatically filter down all Silk4J projects as soon as each project is rebuilt.
For this paper we will make use of the SilkTest WPF Sample Application and the GMO Online sample web application.
The String Variable Approach
Fig.1 below shows a simple script recorded against the WPF Sample Application as exported from the SilkTest Recorder into a Silk4J project.


Fig.1 – Raw locator strings
We need to take each unique locator string and declare it as a string variable - fig.2 below shows this process completed. Each window has been given its own section to make it more easily readable when searching for the original locator.


Fig.2 – Test class global Strings
All strings have been declared as global to the test class so they will be available for all scripts within that test class. We could have left them local to the testcase but that would be self-defeating.
Compare the readability of this converted test script to the original raw code in fig.1. However, there are two fairly serious disadvantages with this approach –

1.       The new string variables are not available across projects.

2.       There is no intellisense, so you need to keep scrolling back to the string source and copying them into the line you are currently coding.

Both of these problems are resolved by using a class library.
 
The Class Library Approach
For large/multiple projects and code portability the class library is definitely the way to go. Once the class library has been compiled the resulting jarfile can be referenced from any Silk4J project; in this respect the class library can be considered as the equivalent of the SilkTest Classic frame file. It is possible to structure the class library so that the resulting intellisense selections have a hierarchical structure similar to the SilkTest frame file.
Creating the Class Library
At this point you will need to sit back, study your application under test very carefully and decide just how you want to structure the class library. For the GMO website test I decided to build the classes based on the individual page layouts to give a setup similar to the SilkTest Classic frame file. You could also build the class library based on object types i.e. button, listview, checkbox, table etc. etc.. A class library based on object types gives faster access to the required object through the intellisense but the page-based setup gives a more familiar intellisense structure to those SilkTest Classic engineers who are migrating to Silk4J or who are looking at starting to work with Silk4J.
To begin building the class library I created a new Silk4J project called (unsurprisingly) GMOTags. The package was given the name of GMO so that all intellisense selections would start with the name of the parent application, much as the SilkTest Classic frame file declarations all start with the parent window name.
Please note that all variables in the classes have to be ‘public static’ for two reasons: ‘public’ means that they will be available for all projects that reference the final jarfile and ‘static’ to ensure that the variable cannot be accidently overwritten by any code further down in the class library or in your test projects. In this case the project is so small that is not likely to happen but it is better to start with security than to find it all fails later.
Each page in the GMO application will be given a separate class in the GMO package. The welcome page for the GMO OnLine website presents a number of obvious candidates for testing. These are the three buttons, the email link, the website title and the website logo.


Fig.3 – GMO OnLine welcome page
To get the locator strings we need the SilkTest Recorder. Setting up the classes for each page or screen of your application can be a long process but, apart from future maintenance and additions, it is a one-off process. If the locator string for an object is unique to that page then we do not need the parent header (in case, the ‘BrowserApplication/BrowserWindow’ part of the locator string).


Fig.4 – GMO OnLine logo locator string
We then assign the remainder of the locator to a public static string.


Fig.5 – Assigning the logo locator string in the OnLine java class
You will then need to continue recording locator strings and assigning them into the initial class until you have captured all of the objects that will need testing on the first page/screen of your application.


Fig.6 – The completed GMO OnLine welcome page class
Note that in creating the strings I have chosen to use a form of camel-case Hungarian notation. This is simply to tell me what the object type is when it is applied to a testcase.
If you have done any work at all with the GMO OnLine sample application (either the website or the client-server version) you will be aware that if you enter an incorrect credit card number on the payment page you will be presented with an error dialog. A browser page has a number of objects that will be common across all webpage applications (unless the application is using a custom browser), so these objects are a good subject for their own class library. Although the GMO application only throws the one dialog box, we will create separate class libraries for the dialog box and the common browser objects. The dialog box and the common browser objects are included in different classes.


Fig.7 – Browser common objects project
When you have completed a class library you will need to create the jarfile.

1.       From the Silk4J menu select File | Export.

2.       When the Export dialog comes up, select ‘Next’

3.        On the JAR Export page select your class library project from the lefthand pane, then enter an export destination in the ‘JAR file’ textfield.

4.       Under ‘Options’ uncheck the ‘Compress the contents of the JAR file’ checkbox if required.

5.       Select ‘Finish’.

Using the Class Library
In the testcase project we need to add a reference to the class libraries that we want to work with.

1.       Right-click on the project name and select ‘Build Path | Configure Build Path’

2.       In the ‘Properties for ’ dialog select ‘Add External JARs...’

3.       Navigate to your class library jarfile, select it, then click ‘Open’.

4.       Repeat (2) and (3) for any additional class libraries.

5.       Select ‘OK’.

You should now see a new folder in your test project called ‘Referenced Libraries’. If you expand the folder you will see the class libraries you have just selected. To invoke a class library you will need to trigger the intellisense by starting with the main package title. Fig.8 (below) is a short recorded test that still has the raw locator strings in it. We will replace all of these strings from the class libraries and then go on to script some verifications.

Fig.8 – A recorded test


Fig.9 – Replacement in progress - Intellisense
If you study the picture of the intellisense box above you will see that Silk4J has a useful helper function in that the last used class (‘Catalog’) is presented at the top of the list. The previous ‘last used’ class (‘Online’) now appears as number two in the list.
To make the script more readable I am entering the page name as a comment whenever we change pages. If you look at the code for the Welcome page you can clearly see that we have called object names from both the GMOTags class library and the BrowserObjects class library. Unfortunately this screenshot also shows a syntax error – the speech marks in the object definition string need to be removed.
Once the conversion is finished we have a much more readable script. If, during the process of scripting you find that you have missed an object from a class library, add the missing object to the relevant class library then compile and export it. To get the testcase project to recognise the change simply refresh the project (press F5).
 The following Silk4J projects are attached to this white paper:-

·         GMORawLocators – the original recorded testcase against the GMO website

·         GMOTags – the class library code for the GMO website tags

·         Common Browser Objects – the class library code for the browser and browser dialog tags

·         GMOwithTags – the raw locators exchanged for the new tags

·         WPFSampleApp – local string conversion for the WPF sample application