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

 I've set up a table-driven scenario. At the end of my data-driven step, it loops back to the beginning of my first scenario context to start the next table row. How do I get it just to loop from the end of the scenario step to the beginning of the scenario step and not keep trying to log in again?

We have been trying to get Twist to work with our SmartGWT user interfaces.  We were never able to get anything working with Sahi.

Recently our search has led us to how SmartGWT initially suggests doing automated unit testing.  In the SmartGWT download there is a Selenium directory that provides a couple of extensions that can be used to lookup SmartGWT ids.  I can get this working with SeleniumIDE and I can record my tests from there.

The problem is that I do not know how to add the file needed to be "seen" by the Selenium running in Twist.

There are plenty of articles for how to do it in Selenium RC, but I don't know how to do it here.

Here is an article for how this is done in RC:

http://seleniumhq.org/docs/08_user_extensions.html

We really like your product and the approach to testing, but we really need some help on this issue (being able to access SmartGWT ids) if we are going to be able to continue to use Twist.