What is Sikuli?

Sikuli is a visual technology to automate and test graphical user interfaces (GUI) using screenshots. You may read more about it here: http://sikuli.org

Installing Sikuli:

You can get the latest version from here: http://sikuli.org/download.shtml

Note: If you are using linux you will need to have wmctrl, and OpenCV 2.1 installed.

Using Sikuli with Twist:

There are two distinct parts to using Sikuli with Twist. The first part involves wiring Twist up to use the Sikuli jars. The second involves getting the screenshots you will require to automate your application.

To wire Twist up with Sikuli:

The Sikuli IDE you downloaded has a jar file called sikuli-script.jar. You can find this jar file under the lib directory of your Sikuli installation. You will need to copy this jar file into a directory called libs(create "libs" if it is not already present) in the Twist project where you intend to use Sikuli.

Now you can let the Twist project know that you have inserted a new library. You may do this by right clicking on the project, selecting "Properties>Java Build Path" and selecting the "Libraries" tab. Click on "Add JARs" and select the sikuli-script.jar by navigating to the libs folder under your twist project. Click on Ok.

The final part of wiring up Sikuli involves the creation of beans in your applicationContext-suite.xml file. Doing this will let Twist know how to instantiate your driver and make it available to your test code. Add the following right at the end of the applicationContext-suite.xml file, just before where it says </beans>:

<bean id="sikuli" class="org.sikuli.script.Screen"/>

This bean will make the "Screen" object available to your test code. You will use the Screen object to interact with your applications.

Now that Sikuli is wired into Twist you will be able to use it in any fixture. To test it, open a scenario you have written, or write a new scenario with a single workflow step under a fixture. Implement the fixture and navigate to the code. Create a constructor for your fixture and introduce the Screen object as a parameter in your constructor. The best way to do this is to type Scree and then press Ctrl-Space to pick from a list of suggestions(make sure you pick the option that has org.sikuli.script in it). Your constructor will then look something like:

public FixtureName(..., Screen screen) {....

If you just typed "Screen screen" instead of using suggestions, you will see Screen underlined in red. This is just letting you know that you haven't included an import statement to import Screen. This is easily remedied by typing the following at the top of your java file:

import org.sikuli.script.Screen;

Automating with Sikuli:

Sikuli works by using screenshots of specific parts of your application(buttons/textboxes etc) and performing actions on them. It is therefore imperative to have those screenshots in your Twist project. You may use the Sikuli IDE to capture the relevant screenshots for the application you are testing and then copy those over to your Twist project under a folder called "images" or something appropriate.

Once these screenshots are in place, the rest of it involves making appropriate calls to Sikuli.

For example if you have captured the Windows "Start" button as one of your screenshots, you can get Twist to click it by using:

screen.click("images/start.png");

inside one of your workflow steps.

Sikuli works very well where your application has common visual components across multiple screens but does not have a driver to easily access these controls. Flash based applications are a good class of applications that can be tested with Sikuli.

Happy testing.

I have a case where in the Login class I want to know which type of browser I am using. What is the mobile server address. What is the version of browser and other settings defined in twist.Properties

I am using the default system web browser instantiated by the twist. Twist version is 2.4.0.12621

Please let me know how to implement this or procedure for the same.

Thanks,

Sarita.

Twist 2.3 is out fresh with loads of new features, enhancements. The following is a peak onto “Twist Project Properties” UI.

Until Twist 2.2, for changing any property of a Twist Project, you had to open the “twist.properties” file and manually edit the properties. While we had good documentation, there always used to be human error factors, little pesky issues of some property not being properly edited, a comma or slash (\) missing out etc etc. Or for that matter, if you would want to run your test against another browser, you would have to enter the “code” manually editing the properties file.

With Twist 2.3, you no longer need to be bothered about such things.  Here’s a screenshot of a Twist Project’s properties for chosen driver as “Selenium2”.

The first tab “General” shows you the twist specific properties.

The properties UI is dynamic and depends on primarily the driver defined for the Twist Project and secondarily on the chosen agent (Browser). For example, following is the properties UI for project with Sahi as Driver.

You can just change the “Browser” from the drop down, and run your scenarios on chosen browser.

The “User” tab shows you any custom property you may have added. This means that any property not recognized by Twist and the chosen driver will appear in the “User” tab.

The properties UI makes test configuration for multiple environments significantly easier.

To test on different browsers, just go to project properties and select “Twist Properties” on the left pane, and change the “Browser” property, and execute a scenario, and the scenario will run on the chosen browser.

Not just that, the editor GUI can edit any properties file under a twist project. So, if you want to manage configuration for multiple environments, just create multiple “<env>.twist.properties” file and edit with the properties editor.

The idea of this post is to demonstrate WebServices testing from Twist. While some of our customers have already been using Twist for services testing, this post will hopefully show you easy enough steps to test your WebServices while still leveraging the authoring, maintenance aspects of Twist. In this example, we will test a simple temperature converter service exposed at http://www.w3schools.com/webservices/tempconvert.asmx, which provides simple celsius to fahrenheit degrees conversion.

Pre-requisite:

• This example is built with Apache CXF 2.4.2, and you should download it from here (http://cxf.apache.org/download.html), and extract the archive to a local directory. Apache CXF is an open source services framework, and allows you test services over a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP etc and over transports such as HTTP, JMS or JBI.
• You should also extract the bundled example project and import it within Twist. It contains a simple Twist project testing the above mentioned service. We are going to refer some classes, configurations, build samples from the example project.

1. Creating the project

• Create a Twist project, with driver of your choice. For the example project, I have chosen "none". But you may as well integrate this with your chosen driver for your mixed-mode testing requirements (like use a web browser interface to place an order, and verify the transaction through a webservices call).

2. Generating the building stubs, skeletons, and data types from WSDL.

What we want is a simple and usable enough java interface for accessing the remote WebService. something like:

  converterService.celsiusToFahrenheit("32")

A fair amount of boilerplate code must be written to access the Service. Thankfully, we can automate all that code generation. We will generate the bindings necessary for client side testing of the service using wsdl2java utility shipped with CXF. To do this:

• Get hold of the wsdl document and place it under the "<project root>/src" folder. For the example, I retrieved the wsdl from from http://www.w3schools.com/webservices/tempconvert.asmx?wsdl and saved the file as - "<project root>/src/tempconvert.asmx.wsdl". Your development team can also provide you the same.  
• Copy 2 files (cxf_wsdl2java.xml and cxf_wsdl2java.properties) from the attached project and place them under <project root>.
• Open the file "cxf_wsdl2java.xml" and change the wsdl src reference under target "cxfWSDLToJava" to "src/tempconvert.asmx.wsdl"
• Open cxf_wsdl2java.properties and change the first property "cxf_home" to home directory of CXF. (e.g cxf_home=/<directory>/apache-cxf-2.4.2)
• Open the "Ant View" (Window -> Show View -> Ant) and drag and drop the "cxf_wsdl2java.xml" to the view and then run target "cxfWSDLToJava".
• Once run, you should see the generated code under "src" folder within package "org.tempuri"

If you look within the package contents classes, you will find an interface annotated with @WebService (org.tempuri.TempConvertSoap). This interface has 2 basic methods that represent the operations supported by the WebService. This is the remote interface we are going to use in our Test fixtures.

Another class (org.tempuri.TempConvert) will be generated annotated with @WebServiceClient. This is the class that will return the remote interface. Methods annotated with @WebEndpoint will return you a remote interface. (in this case, we have used TempConvert.getTempConvertSoap() method)

NOTE: If you would want to customize the JAX-WS implementations created by wsdl2java, it can be done by using a customization binding file. Please refer here for more information.

3. Adding CXF Library references to your project

• Go to "project properties->java build path->libraries tab"
• Add "external jars" references to cxf-2.4.2.jar, neethi-3.0.1.jar, wsdl4j-1.6.2.jar, xmlbeans-2.4.0.jar, xmlschema-core-2.0.jar (all these are found under <cxf_home>/lib/ folder)

4. Creating the remote interface instance

• From the example project, copy the org.example.ConverterServiceFactory java file to your project, under package org.example
• Open the scenarioContext-suite.xml file from your project and configure 2 beans like below (these will provide you the TempConvertSoap interface).

<bean id="tempConvertorFactory" class="org.example.ConverterServiceFactory"
     init-method="start" destroy-method="stop" lazy-init="true">
     <property name="wsdlLocation" value="classpath:tempconvert.asmx.wsdl"/>
</bean>
 
<bean id="converterService" factory-bean="tempConvertorFactory" factory-method="getConverterServicePort"
      lazy-init="true" scope="singleton">
</bean>

5. Creating a scenario and generating test fixture

• Assuming that you have a scenario "convert celsius.scn" (refer to the example project) which stated something like:

 Temperature Converter:

•   verify that "100" degrees in centigrade is same as "212" degrees fahrenheit

• Implement the step in fixture "Temperature Converter" (CMD+1 or right click ->quick fix) . This would have generated a fixture and a dummy implementation of the step. Navigate to the code for the step (right click -> show code). We need to hook up the service interface here.

6. Injecting the service interface to the fixture

• We can leverage Spring's annotation based configuration to inject the remote interface by simple declaring a private variable and annotating with @Autowired like below

public class TemperatureConverter {
    
    @Autowired
    private TempConvertSoap converterService;
    ....
    
}  

7. Calling a remote service operation.

• Navigate to the code for the step (right click -> show code). Now you are can use the remote interface like below:

public void verifyThatDegreesInCentigradeIsSameAsDegreesFahrenheit(Double celsius, Double fahrenheit) throws Exception {
        assertEquals(fahrenheit, Double.valueOf(converterService.celsiusToFahrenheit(celsius.toString())));
 }

8. Execute the scenario

• You should see the scenario executing correctly.

Additional support from Eclipse WTP