Testing – RedStack

Running SCA Tests from Maven

Mark Nelson — Thu, 10 Jul 2014 23:59:59 +0000

In this post, let’s look at how we can run SCA test suites from Maven.

To get started, we are going to need a test. Let’s set up our process to add two numbers. Go ahead and open the XML Schema for the inputs and outputs and change it to take two int’s as input and return a single int as output, as shown below:

Now update the assign activity’s copy rule in the BPEL process to add the two numbers together. The “from” part of the copy rule should look like this:

$inputVariable.payload/client:a + $inputVariable.payload/client:b

Now, let’s define a test.

Right click on the testsuites folder, and choose Create Test Suite. Give it a name like test_suite1. Then the Create Composite Test wizard will open. Click on Next twice to get to the Input Message page. Click on Generate Sample and set the values for a and b to 1 and 2, like this:

http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1">
  1
  2

Click on Next and then Generate Sample again and set the output to look like this:

http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1">
  3

Click on Finish. Now we have a test.

Next, we need to create a jndi.properties file. This file is required by sca-test – regardless of whether you run it from ANT or Maven, etc.

Create a new file in your project and set up the content like this:

java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.provider.url=t3://my.server:7003/soa-infra
java.naming.security.principal=weblogic
java.naming.security.credentials=welcome1
dedicated.connection=true
dedicated.rmicontext=true

We also need to update the POM to tell Maven where the jndi.properties is located.

Open the POM, uncomment the jndi.properties.input property and make sure it points to the right file. If you called your file jndi.properties and put it in the root of your project, then the example provided in the POM is the right value for you.



${basedir}/jndi.properties
${scac.output.dir}/testResult

soaProject1

Now you can run the tests by executing the Maven verify goal – either in JDeveloper or from the command line.

The output will look something like this:


C:\src2\soaApp1>mvn verify
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.redstack:soaProject1:sar:1.0-SNAPSHOT
[WARNING] The expression ${version} is deprecated. Please use ${project.version} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] soaProject1
[INFO] soaApp1
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building soaProject1 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ soaProject1 ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\src2\soaApp1\soaProject1\src\main\resources
[INFO] Copying 1 resource
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:compile (default-compile) @ soaProject1 ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - COMPILE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] ABOUT TO RUN oracle.soa.scac.ValidateComposite...
[INFO] The environment variable/property 'oracle.home' is not set.
[INFO] If you want to compile a composite with a component that depends
on MDS - like a Human Task or Business Rule - AND you want to use a file
based MDS repository, you will need to specify 'oracle.home' OR update
your .adf/META-INF/adf-config.xml to point to your file-based MDS.
If you specify oracle.home it must point to the SOA Quickstart or
JDeveloper install directory with '/soa' appended to it, unless you
update the adf-config.xml to remove the reference to oracle.home.
[INFO] compile: Executing: [cmd:[c:\java\jdk1.8.0_05\bin\java, -Djava.protocol.handler.pkgs=oracle.mds.net.protocol|oracle.fabric.comm
on.classloaderurl.handler|oracle.fabric.common.uddiurl.handler, oracle.soa.scac.ValidateComposite, C:\src2\soaApp1\soaProject1/SOA//co
mposite.xml, -level=1]]
[INFO] Process being executed, waiting for completion.
[INFO] [exec] Jul 11, 2014 9:57:39 AM oracle.fabric.common.wsdl.SchemaManager isIncrementalBuildSupported
[INFO] [exec] INFO: XMLSchema incremental build enabled.
[INFO] [exec] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] [exec] >> modified xmlbean locale class in use
[INFO] [exec] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[INFO] compile: [cmd:[c:\java\jdk1.8.0_05\bin\java, -Djava.protocol.handler.pkgs=oracle.mds.net.protocol|oracle.fabric.common.classloa
derurl.handler|oracle.fabric.common.uddiurl.handler, oracle.soa.scac.ValidateComposite, C:\src2\soaApp1\soaProject1/SOA//composite.xml
, -level=1]] exit code=0
[INFO] SOA COMPILE DONE
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ soaProject1 ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\src2\soaApp1\soaProject1\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ soaProject1 ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.17:test (default-test) @ soaProject1 ---
[INFO] No tests to run.
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:sar (default-sar) @ soaProject1 ---
[INFO] Building sar: C:\src2\soaApp1\soaProject1\target\sca_soaProject1_rev1.0-SNAPSHOT.jar
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:deploy (default-deploy) @ soaProject1 ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE SOA MAVEN PLUGIN - DEPLOY COMPOSITE
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] setting user/password..., user=weblogic
Processing sar=C:\src2\soaApp1\soaProject1/target/sca_soaProject1_rev1.0-SNAPSHOT.jar
Adding sar file - C:\src2\soaApp1\soaProject1\target\sca_soaProject1_rev1.0-SNAPSHOT.jar
INFO: Creating HTTP connection to host:slc05evl.us.oracle.com, port:7003
INFO: Received HTTP response from the server, response code=200
---->Deploying composite success.
[INFO]
[INFO] --- oracle-soa-plugin:12.1.3-0-0:test (default-test) @ soaProject1 ---
[INFO] native formatting
[INFO] native
[INFO] [http://xmlns.oracle.com/sca/2006/test">http://xmlns.oracle.com/sca/2006/test">







http://xmlns.oracle.com/soaApp1/soaProject1/BPELProcess1">
3




http://xmln
s.oracle.com/soaApp1/soaProject1/BPELProcess1">3]
[INFO] C:\Users\Mark\AppData\Local\Temp\out\oracle-soa-plugin-scatest.xml
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building soaApp1 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] soaProject1 ....................................... SUCCESS [01:31 min]
[INFO] soaApp1 ........................................... SUCCESS [  0.002 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:38 min
[INFO] Finished at: 2014-07-11T09:58:55+10:00
[INFO] Final Memory: 15M/91M
[INFO] ------------------------------------------------------------------------

Now, if you were running this build in a CI server, like Hudson, then you could have it collect the results and chart them for you.

In the next post, let’s add some more interesting things to our SOA Application.

Manipulating Human Tasks (for testing)

Mark Nelson — Sat, 08 Mar 2014 10:01:46 +0000

A few months ago, while working on a BPM migration, I had the need to look at the status of human tasks, and to manipulate them – essentially to just have a single user take random actions on them at some interval, to help drive a set of processes that were being tested.

To do this, I wrote a little utility called httool. It reuses some of the core domain classes from my custom worklist sample (with minimal changes to make it a remote client instead of a local one).

I have not got around to documenting it yet, but it is pretty simple and fairly self explanatory. So I thought I would go ahead and share it with folks, in case anyone is interested in playing with it.

You can get the code from my ci-samples repository on java.net:

git clone git://java.net/ci4fmw~ci-samples

It is in the httool directory.

I do plan to get back to this “one day” and enhance it to be more intelligent – target particular task types, update the payload, follow a set of “rules” about what action to take – so that I can use it for more driving more interesting test scenarios. If anyone is feeling generous with their time, and interested, please feel free to join the java.net project and hack away to your heart’s content.

How to tell if the SOA Platform is running

Mark Nelson — Wed, 15 Jan 2014 19:43:08 +0000

When you start up a SOA managed server, there is a time interval when the managed server is up, but the SOA platform is not yet up. This is the time while SOA is loading all of the composites, and so on. Sometimes we want to know when SOA is actually ready, not just the managed server, but the soa-infra application. For example, if we wanted to start testing a composite, there would be no point doing that until SOA was running.

So it seems like a common requirement to be able to tell when SOA is ready. The most reliable way to do this is to check an MBean, and to make that available to an external waiting process (like a build job) we can expose the check using a simple Servlet.

In this post, we will look at how to do just that. The code in the sample is available in my git repo on java.net, you can grab it with:

git clone git://java.net/ci4fmw~ci-samples

Then look in the is-soa-running directory.

The code in this sample was written by Robert Patrick, and it is set up to build and deploy with Maven. It is written for SOA 11.1.1.7, but it will work for other versions too.

There is one library from SOA Suite that you will need to compile this code. Since we don’t have the libraries in any public Maven repository, you will need to add this library into your own Maven repository using a command like this:

mvn install:install-file
   -Dfile=/path/to/soahome/oracle_common/modules/oracle.jmx_11.1.1/jmxframework.jar
   -DgeneratePom=true
   -DgroupId=com.oracle.soa
   -DartifactId=jmxframework
   -Dversion=11.1.1.7
   -Dpackaging=jar

This will allow us to use that library in our build.

Let’s take a look at the project. We have a POM to build the project, a simple Java class to check the MBean, a simple Servlet to present the result, and some basic deployment descriptors. First, let’s look at the code that checks the MBean, this is in src/main/java/com/redstack/CheckSOAStatus.java:

package com.redstack;

/**
* @author robert.patrick
*/

import java.io.IOException;
import javax.management.MBeanServer;
import javax.management.ObjectName;
import javax.management.openmbean.CompositeDataSupport;

import oracle.as.jmx.framework.PortableMBeanFactory;

public final class CheckSOAStatus
{

  /**
   * check whether the SOA platform is running on this server
   */
  public static boolean checkStatus(String serverName) throws IOException
  {
    MBeanServer server = null;
    try {
      server = new PortableMBeanFactory().getMBeanServer();
    }
    catch (Exception e) {
      String msg = "PortableMBeanFactory.getMBeanServer() failed: " +
      e.getMessage();
      System.err.println(msg);
      e.printStackTrace(System.err);
      throw new IOException(msg, e);
    }

    ObjectName name;
    try {
      name = new ObjectName("oracle.soa.config:name=soa-infra,j2eeType=CompositeLifecycleConfig,Application=soa-infra");
    }
    catch (Exception e) {
      String msg = "Malformed Object Name: " + e.getMessage();
      System.err.println(msg);
      e.printStackTrace(System.err);
      throw new IOException(msg, e);
    }

    Boolean isReady;
    try {
      CompositeDataSupport compositeData = (CompositeDataSupport)
      server.getAttribute(name, "SOAPlatformStatus");
      isReady = (Boolean)compositeData.get("isReady");
    }
    catch (Exception e) {
      String msg = "Error getting MBean data: " + e.getMessage();
      System.err.println(msg);
      e.printStackTrace(System.err);
      throw new IOException(msg, e);
    }
    return isReady.booleanValue();
  }
}

Basically, we are connecting to the MBean server, and looking up an object named oracle.soa.config:name=soa-infra,j2eeType=CompositeLifecycleConfig,Application=soa-infra, then getting the SOAPlatformStatus attribute and then checking isReady. This gives us a true if SOA is finished starting up, or a false otherwise.

Now let’s take a look at the Servlet:

package com.redstack;

/**
* @author robert.patrick
*/
import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class CheckSOAStatusServlet extends HttpServlet
{
  public void doGet(HttpServletRequest req, HttpServletResponse res)
  throws ServletException, IOException
  {
    String serverName = System.getProperty("weblogic.Name");
    boolean status = CheckSOAStatus.checkStatus(serverName);
    if (status) {
      res.setStatus(HttpServletResponse.SC_OK);
      PrintWriter out = res.getWriter();
      out.println("Check SOA Status\n");
      out.println("SOA Server on " + serverName +
      " is finished loading its composites.");
    }
    else
      res.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE,
      "SOA Server on " + serverName +
      " is not finished loading its composites.");
    }
  }

Here we are basically just calling that class to have it check the status and reporting it back in the output. We also set the HTTP status code differently, so we can either check the text, or just the HTTP code to get the outcome.

Here is the web.xml:



  
    Check SOA Status Servlet
    com.redstack.CheckSOAStatusServlet
    
      soa-admin
    
  
  
    Check SOA Status Servlet
    /statuscheck
  
  
    /statuscheck
  
  
    soa-admin

We are just mapping the Servlet to a URL – /statuscheck in this case, and also we define a role that this Servlet needs to run as. As we can see in the WebLogic deployment descriptor, we map this to the administration user:



  
    soa-admin
    weblogic

The POM is also fairly straight forward:



  4.0.0
  com.redstack
  statuscheck
  1.0-SNAPSHOT
  war
  statuscheck
  
    
      javax
      javaee-web-api
      6.0
      provided
    
    
      com.oracle.soa
      jmxframework
      11.1.1.7
      provided
    
  
  
    statuscheck
    
      
        org.apache.maven.plugins
        maven-compiler-plugin
        2.3.2
        
          1.6
          1.6
        
      
      
        org.apache.maven.plugins
        maven-war-plugin
        2.1.1
        
          false
        
      
      
        com.oracle.weblogic
        weblogic-maven-plugin
        12.1.2-0-0
        
          
          
            deploy
            pre-integration-test
            
              deploy
            
            
              
              http://your.server:7001
              weblogic
              welcome1
              
              ${project.build.directory}/${project.build.finalName}.${project.packaging}
              
              soa_server1
              true
              ${project.build.finalName}

We set the project coordinates, and list our two dependencies – the jmxframework library we saw earlier and the Java EE WebApp API. Then we have the normal configuration to tell Maven what version of Java to use to compile this, and how to build the WAR.

The weblogic-maven-plugin entry in the build section demonstrates how you could use the WebLogic Maven Plugin’s deploy goal to deploy the WAR to a server.

Then you can simply hit http://your.server:8001/checkstatus to see if SOA is fully up and running.

Enjoy!

Writing a Robot Remote Library

Mark Nelson — Mon, 21 Oct 2013 21:07:20 +0000

After reading the quick introduction to Robot Framework, you might have been asking yourself “so, what else can I do with this Robot thing?” – well there are, of course, a lot of things you can do with it. Today, I want to take a look at writing Remote Libraries.

Robot Framework is extensible through a library mechanism. You can write libraries in Java or Python, or you can wrtie a remote library, which just has to be an XMLRPC server – the implementation language is not important.

One thing that I think we are going to want in the future, when we start provisioning environments using tools like Chef, is a way to check that we got what we wanted. So, I decided to start writing a little Robot library that we could use to check that an environment is configured the way we think it is, or expect it to be. Obviously there are other ways to do this, perhaps better ways, like exposing the configuration through Ohai for example, but I wanted to write a Robot Remote Library, and this seemed like a reasonable example.

So what will our library do? Well, we will build it as a simple Web Application (WAR) that we will deploy on to our WebLogic Admin Server, and we will allow it to answer some simple questions like:

Does the server called ‘AdminServer’ exist?
Is the application called ‘Something’ in the state ‘RUNNING’?
Does the data source called ‘Something’ exist?
and so on…

You could imagine that we could go on extending this to let us ask questions about SOA, OSB, or anything running on WebLogic Server. To answer the questions, we will just go read information out of MBeans, and since Fusion Middleware products conveniently put configuration information in MBeans, it is relatively straightforward for us to go get it.

And since we are building a Robot library, let’s also use Robot to test it! We will build it with Maven, and use the Maven Robot Framework plugin to execute our tests.

So, before we get started, let’s take a quick look at how remote libraries work. You might want to take a quick look at some of the documentation here.

But what we need to know right now is the following:

Robot will make calls to the remote library using XML-RPC over HTTP
It expects (requires) there to be no prefix on the keywords
It will first call get_keyword_names to get a list of the keywords that the library supports
When you ask it to do something, it will call run_keyword to run the keyword you asked for

Keywords (you may recall) are used in the test case to express what must be done to execute the test. So, let’s do a little test driven development, and start with our test case:

*** Settings ***
Library  Remote  http://localhost:7001/oracleRobot/xmlrpc

*** Test Cases ***

Ping Test
   ${pong} =                        ping              bob
   Should Be Equal as Strings       ${pong}           pong bob

Server State Test
   Server Status Should be          AdminServer       RUNNING

Application State Test
   Application Status Should Be     oracleRobot       ACTIVE

Data Source Existence Test
   Data Source Should Exist         myDataSource

You can see that it tells Robot the URL to call the XMLRPC Remote Library in the Settings section. The keyword ‘Remote’ tells it that is it a remote (as opposed to local or built-in) library.

In the test cases you can see the keywords we are going to define, and also surmise their arguments and return values:

Keyword	Arguments	Return Value
ping	a message	the same message
Server Status Should Be	server name, state
Application Status Should Be	application name, state
Data Source Should Exist	data source name

Some of them don’t seem to have return values – that is because the protocol has a built in set of return values to tell Robot if the test was successful or failed (plus some more information about failures – we’ll see this later on), so we don’t need to define our our output to indicate success.

At this point, if you want to follow along with the code, you can grab it from java.net using git:

git clone git://java.net/ci4fmw~robot

Ok, let’s set about building our project. First we will create a Maven POM to describe the project and handle all of the dependencies we need.

First, we are going to need three dependencies:

com.oracle.weblogic:weblogic-server-pom:12.1.2-0-0, type=pom, scope=provided
org.apache.xmlrpc:xmlrpc-server:3.1.3
org.apache.xmlrpc:xmlrpc-common:3.1.3

You will need to populate your Maven repository with the WebLogic Server artifacts using the Maven Synchronization Plugin. You can find details in the documentation here, and an example in this earlier post/video.

Next, we can set up our build section. We need to tell the maven-compiler-plugin to use Java 1.6, we need to configure the maven-war-plugin to create the WAR file, and we need to set up the weblogic-maven-plugin to deploy our WAR to our WebLogic Server instance for testing.

Finally, we need to tell Maven to grab the robotframework-maven-plugin and run the test suite.

Here is what our finished POM looks like:



  4.0.0
  com.oracle.maven
  oracle-robot
  1.0-SNAPSHOT
  war
  oracleRobot
  
    t3://localhost:7001
    AdminServer
  
  
    
      com.oracle.weblogic
      weblogic-server-pom
      12.1.2-0-0
      pom
      provided
    
    
      org.apache.xmlrpc
      xmlrpc-server
      3.1.3
    
    
      org.apache.xmlrpc
      xmlrpc-common
      3.1.3
    
  
  
    oracleRobot
    
      
        org.apache.maven.plugins
        maven-compiler-plugin
        2.3.2
        
          1.6
          1.6
        
      
      
        org.apache.maven.plugins
        maven-war-plugin
        2.1.1
        
          false
        
      
      
        com.oracle.weblogic
        weblogic-maven-plugin
        12.1.2-0-0
        
        
        
          
            wls-deploy
            pre-integration-test
            
              deploy
            
            
              ${serverUrl}
              weblogic
              welcome1
              ${project.build.directory}/${project.build.finalName}.${project.packaging}
              ${serverName}
              true
              true
              true
              ${project.build.finalName}
            
          
       
       
       
      
      
        org.robotframework
        robotframework-maven-plugin
        1.1
        
          
            
              run

Now, as we know from this earlier post we place the test suite in a directory called src/test/robotframework/acceptance. I called mine mytest.txt. The full source for the test is just up above.

Next, we are going to need a web.xml for the Web Application, so let’s create that. It goes in src/main/webapp/WEB-INF and here is what it looks like:




  
    30
  
  
    index.html
  
  
    XmlRpcServlet
    com.oracle.maven.MyXmlRpcServlet
    
      enabledForExtensions
      true
    
  
  
    XmlRpcServlet
    /xmlrpc

Here we are telling it the name of the servlet we will use to handle the XML-RPC requests and mapping it to the url /xmlrpc. Notice that we also set enabledForExtensions to true, because we are going to define our our handler since the library we are using assumes prefixes are required, but we actually do not want prefixes.

Let’s look at the servlet – here is the code:

package com.oracle.maven;

import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.server.XmlRpcHandlerMapping;
import org.apache.xmlrpc.webserver.XmlRpcServlet;

/**
 *  An XMLRPC servlet.
 *  The Robot Framework allows for the definition of a remote library
 *  using an XML RPC protocol. In this class, we implement an XMLRPC
 *  server as a servlet.  The Apache XMLPRC library that we are using
 *  creates services with a prefix, e.g. Robot.ping, however Robot
 *  expects there to be no prefix, e.g. just ping, so we need to add
 *  a little logic to remove the prefixes.
 */
public class MyXmlRpcServlet extends XmlRpcServlet  {

  /**
   *  Register a new HandlerMapping and remove prefixes.
   */
  @Override
  protected XmlRpcHandlerMapping newXmlRpcHandlerMapping() throws XmlRpcException {
    HandlerMapping mapping = new HandlerMapping();
    mapping.addHandler(com.oracle.maven.Robot.class.getName(), com.oracle.maven.Robot.class);
    mapping.removePrefixes();
    return mapping;
  }

}

Basically all we are doing here is registering our custom handler that removes the prefixes so that our XML-RPC services look the way Robot wants them to look.

Let’s take a look at that handler, here is the source:

Please note that this was adapted from here and is licensed under the Apache License, Version 2.0 – see the source file for more details.

package com.oracle.maven;

import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Set;

import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.server.AbstractReflectiveHandlerMapping;

/**
 *  A HandlerMapping that removes the prefixes of service names.
 */
public class HandlerMapping extends AbstractReflectiveHandlerMapping {

    /**
     * Removes the prefixes from all keys in this handler mapping assuming a
     * String was used as the key and period was
     * used as a separator. Example: Robot.getInvoice -> getInvoice
     */
    @SuppressWarnings("unchecked")
    public void removePrefixes() {
      Map newHandlerMap = new HashMap();
      for (Entry entry : (Set>) this.handlerMap.entrySet()) {
        String newKey = (String) entry.getKey();
        if (entry.getKey() instanceof String) {
          String key = (String) entry.getKey();
          if (key.contains(".")) {
            newKey = key.substring(key.lastIndexOf(".") + 1);
          }
        }
        newHandlerMap.put(newKey, entry.getValue());
      }
      this.handlerMap = newHandlerMap;
    }

    /**
     * Adds handlers for the given object to the mapping. The handlers are build by invoking
     * {@link #registerPublicMethods(String, Class)}.
     *
     * @param pKey
     *            The class key, which is passed to {@link #registerPublicMethods(String, Class)}.
     * @param pClass
     *            Class, which is responsible for handling the request.
     */
    public void addHandler(String pKey, Class pClass) throws XmlRpcException {
      registerPublicMethods(pKey, pClass);
    }
}

Basically this is just going to go through the service names, which will something like Robot.MyService, and remove the prefix, so that it is just MyService. We need to do this because that is the way Robot expects the services to be. These two classes (the servlet and the handler) are actually generic – you should not need to make any changes to them (other than the class names in the servlet) to use them in another Robot Remote Library.

Now, we get to the class that does all the work. The one that actually implements the keywords we will be using. Here is the code:

package com.oracle.maven;

import java.util.Map;
import java.util.HashMap;

import javax.management.MBeanServer;
import javax.management.ObjectName;
import javax.management.MalformedObjectNameException;
import javax.naming.InitialContext;

/**
 *  A Remote Library for Robot Framework that defines keywords for Fusion Middleware.
 *  This is remote library for the Robot Framework, which can be deployed on a WebLogic
 *  Server and can be used in Robot Test Suites to obtain information about the
 *  WebLogic Domain.  This is mainly useful for 'infrastructure' level tests, for
 *  example, it will answer questions like:
 *  
 *  

 *  Does a given server have a given state?
 *  Is a given application deployed?
 *  Does a given DataSource exist?
 *  
 *  
 *  This remote library uses WebLogic MBeans, and so it must be deployed on the
 *  AdminServer, not a managed server.
 *  The Robot protocol uses xmlrpc with no prefixes.
 *  

 *  How to use:
 *  

 *  Suppose this robot is deployed on context root /oracleRobot.
 *  In your Test Suite, you access it by declaring a remote library in the Settings section
 *  then you may use keywords from this library in your Test Cases section.
 *  For example:
 *  

 *  
 *  *** Settings ***
 *  Library  Remote  http://server:port/oracleRobot
 *
 *  *** Test Cases ***
 *  Server Status Should Be   AdminServer    RUNNING
 *  Application Should Be     myWebApp       Active
 *  Data Source Should Exist  myDataSource
 *  
 *
 *  
 *  Robot looks for keywords by removing capitals and replacing spaces with
 *  underscores, so in the example above, when we say 'Server Status Should Be',
 *  it will call an XMLRPC method names 'server_status_should_be'.
 *  

 *  Note that Robot is a Python-based framework, and hence this class contains
 *  method names that follow the Python, rather than Java, naming conventions.
 */
public class Robot {

  private static final ObjectName domainRuntime;
  private static final ObjectName runtime;

  // string literals
  private static final String STATUS    = "status";
  private static final String ERROR     = "error";
  private static final String TRACEBACK = "traceback";
  private static final String RETURN    = "return";
  private static final String EMPTY     = "";
  private static final String PASS      = "PASS";
  private static final String FAIL      = "FAIL";

  private static final String NYI       = "Not Yet Implemented";

  // Initializing the object name for DomainRuntimeServiceMBean
  // so it can be used throughout the class.
  static {
    try {
      domainRuntime = new ObjectName(
          "com.bea:Name=DomainRuntimeService,Type=weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean");
    } catch (MalformedObjectNameException e) {
      e.printStackTrace();
      throw new AssertionError(e.getMessage());
    }
  }

  // Initializing the object name for RuntimeServiceMBean
  // so it can be used throughout the class.
  static {
    try {
      runtime = new ObjectName(
          "com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime.RuntimeServiceMBean");
    } catch (MalformedObjectNameException e) {
      e.printStackTrace();
      throw new AssertionError(e.getMessage());
    }
  }

  //
  // these are the methods that implement Robot keywords
  //

  /**
   *  A Robot keyword that simply returns a message acknowledging its existense.
   *  Mainly to be used to check that the remote robot library is functioning.
   *
   *  @param args An Object[1] where args[0] contains
   *              a message to be echoed back.
   *  @return The robot protocol formatted return object containing the message.
   */
  public HashMap ping(Object args[]) {
    // prepare the result object
    HashMap result = new HashMap();
    // actual logic of the keyword goes here
    // TODO: check input is correct arity
    Object returnObj = "pong " + args[0];
    // create the response
    result.put(STATUS, PASS);
    result.put(ERROR, EMPTY);
    result.put(TRACEBACK, EMPTY);
    result.put(RETURN, returnObj);
    return result;
  }

  /**
   *  A Robot keyword that checks that a Data Source exists.
   *
   *  @param args An Object[1] where args[0] contains
   *              the name of the DataSource you want to confirm exists.
   *  @return The robot protocol formatted return object containing status of
   *          pass if the DataSource exists or fail otherwise.
   */
  public HashMap data_source_should_exist(Object args[]) {
    // prepare the result object
    HashMap result = new HashMap();
    // actual logic of the keyword goes here
    // TODO: check input is correct arity
    Object returnObj = EMPTY;
    // create the response
    result.put(STATUS, PASS);
    result.put(ERROR, NYI);
    result.put(TRACEBACK, EMPTY);
    result.put(RETURN, returnObj);
    return result;
  }

  /**
   *  A Robot keyword that checks the status of a server.
   *  This keyword allows you to check the status of a WebLogic Server against
   *  a state that you expect it to have.  If the server state matches your
   *  expectation, the keyword will pass, otherwise it will fail.
   *
   *  @param args An Object[2] where args[0] contains
   *              a the name of the server, e.g. AdminServer and
   *              args[1] contains the desired state, e.g.
   *              RUNNING.
   *  @return The robot protocol formatted return object indicating pass/fail.
   */
  public HashMap server_status_should_be(Object args[]) {
    // prepare the result object
    HashMap result = new HashMap();
    // actual logic of the keyword goes here
    // TODO: check input is correct arity
    InitialContext ctx;
    boolean found = false;
    try {
      ctx = new InitialContext();
      MBeanServer server = (MBeanServer)ctx.lookup("java:comp/env/jmx/domainRuntime");
      ObjectName[] serverRuntimes = (ObjectName[]) server.getAttribute(domainRuntime, "ServerRuntimes");
      for (int i = 0; i < serverRuntimes.length; i++) {
        String serverName = (String) server.getAttribute(serverRuntimes[i], "Name");
        String serverState = (String) server.getAttribute(serverRuntimes[i], "State");
        if (((String)args[0]).compareTo(serverName) == 0) {
          // correct server
          if (((String)args[1]).compareTo(serverState) == 0 ) {
            // correct state
            found = true;
            break;
          }
        }
      }
    } catch (Exception e) {
      result.put(STATUS, FAIL);
      result.put(ERROR, e.getMessage());
      result.put(TRACEBACK, e.getStackTrace());
      result.put(RETURN, EMPTY);
      return result;
    }
    // create the response
    result.put(STATUS, found ? PASS : FAIL);
    result.put(ERROR, EMPTY);
    result.put(TRACEBACK, EMPTY);
    result.put(RETURN, EMPTY);
    return result;
  }

  /**
   *  A Robot keyword that checks the status of an application.
   *  This keyword allows you to check the status of an application against
   *  a state that you expect it to have.  If the application state matches your
   *  expectation, the keyword will pass, otherwise it will fail.
   *  

   *  Allowed states are ACTIVE, ACTIVE_ADMIN and INACTIVE.
   *
   *  @param args An Object[2] where args[0] contains
   *              a the name of the application, e.g. myWebApp and
   *              args[1] contains the desired state, e.g.
   *              ACTIVE.
   *  @return The robot protocol formatted return object indicating pass/fail.
   */
  public HashMap application_status_should_be(Object args[]) {
    // prepare the result object
    HashMap result = new HashMap();
    // actual logic of the keyword goes here
    // TODO: check input is correct arity
    InitialContext ctx;
    boolean found = false;
    try {
      // decode state
      int targetState = -1;
      if (((String)args[1]).compareTo("INACTIVE") == 0 ) {
        targetState = 0;
      } else if (((String)args[1]).compareTo("ACTIVE_ADMIN") == 0 ) {
        targetState = 1;
      } else if (((String)args[1]).compareTo("ACTIVE") == 0 ) {
        targetState = 2;
      }
      if (targetState == -1) {
        throw new Exception("You provided an invalid state.  Valid states are ACTIVE, ACTIVE_ADMIN and INACTIVE");
      }
      // now look up the application state
      ctx = new InitialContext();
      MBeanServer server = (MBeanServer)ctx.lookup("java:comp/env/jmx/runtime");
      ObjectName serverRuntime = (ObjectName) server.getAttribute(runtime, "ServerRuntime");
      ObjectName[] appRuntimes = (ObjectName[]) server.getAttribute(serverRuntime, "ApplicationRuntimes");
      for (int i = 0; i < appRuntimes.length; i++) {
        String appName = (String) server.getAttribute(appRuntimes[i], "ApplicationName");
        int appState = (Integer) server.getAttribute(appRuntimes[i], "ActiveVersionState");
        if (((String)args[0]).compareTo(appName) == 0) {
          // correct application
          if (appState == targetState) {
            // correct state
            found = true;
            break;
          }
        }
      }
    } catch (Exception e) {
      e.printStackTrace(System.out);
      result.put(STATUS, FAIL);
      result.put(ERROR, e.getMessage());
      result.put(TRACEBACK, e.getStackTrace());
      result.put(RETURN, EMPTY);
      return result;
    }
    // create the response
    result.put(STATUS, found ? PASS : FAIL);
    result.put(ERROR, EMPTY);
    result.put(TRACEBACK, EMPTY);
    result.put(RETURN, EMPTY);
    return result;
  }

  //
  // methods required by the robotframework remote library protocol follow
  //

  /**
   *  Get a list of Robot keywords implemented in this remote library.
   *  This method is required by the Robot remote library protocol.
   *
   *  @return A String[] containing the names of the keywords
   *          that are implemented by this library.
   */
  public String[] get_keyword_names() {
    // TODO: change this to use reflection?
    return new String[] { "ping",
                          "server_status_should_be",
                          "application_status_should_be",
                          "data_source_should_exist"
                        };
  }

  /**
   *  Run the given keyword.
   *  This method is required by the Robot remote library protocol.
   *  

   *  The expected return object is a Map containing the
   *  following entries:
   *  

   *  

   *  status: Indicates if the keyword was successful, values
   *  are PASS or FAIL.
   *  return: The (arbitrary) return object/message from the
   *  keyword.
   *  error: The error message, if any.
   *  traceback: Additional information, such as a stack trace,
   *  for diaganosing errors.
   *  
   *
   *  @param keyword The name of the keyword to run.
   *  @param args The arguments for the keyword, in an Object[].
   *  @return The result of executing the keyword, formatted as the Robot
   *          framework expects.
   */
  public HashMap run_keyword(String keyword, Object[] args) {
    HashMap kr = new HashMap();
    try {
      // run the right method
      // TODO: change this to use reflection perhaps?
      if (keyword.equalsIgnoreCase("ping")) {
        kr = ping(args);
      } else if (keyword.equalsIgnoreCase("server_status_should_be")) {
        kr = server_status_should_be(args);
      } else if (keyword.equalsIgnoreCase("application_status_should_be")) {
        kr = application_status_should_be(args);
      } else if (keyword.equalsIgnoreCase("data_source_should_exist")) {
        kr = data_source_should_exist(args);
      } else {
        kr.put(STATUS, FAIL);
        kr.put(RETURN, EMPTY);
        kr.put(ERROR, EMPTY);
        kr.put(TRACEBACK, EMPTY);
      }
    } catch (Exception e) {
      e.printStackTrace(System.out);
    }
    return kr;
  }

}

So let’s take a look at this class. Right up top we define a few constants and some statics to refer to the roots of the DomainRuntimeService and RuntimeService JMX trees in WebLogic.

Then we move on to define our keywords. The first one is a really simple ‘ping’:

  public HashMap ping(Object args[]) {
    // prepare the result object
    HashMap result = new HashMap();
    // actual logic of the keyword goes here
    // TODO: check input is correct arity
    Object returnObj = "pong " + args[0];
    // create the response
    result.put(STATUS, PASS);
    result.put(ERROR, EMPTY);
    result.put(TRACEBACK, EMPTY);
    result.put(RETURN, returnObj);
    return result;

This shows us how the Robot protocol works. First of all, we are going to receive the inputs in an array of Objects, and we are going to send the result in a HashMap. That result hashmap has a number of entries in it:

status, which tells Robot is the test passed or failed
error, which identifies the error (if any)
traceback, which provides more context for the error
return, which is our general purpose object for sending back any data we wish to send

In this example, we are setting the return entry to contain “pong ” plus whatever we got as input in the first parameter. Now, in real life, you would obviously want to be a little more careful about checking that parameters were passed and about typecasting them, but this is an example

Let’s look at a slightly more interesting keyword. This one allows us to check the state of a server. Here is the code:

  public HashMap server_status_should_be(Object args[]) {
    // prepare the result object
    HashMap result = new HashMap();
    // actual logic of the keyword goes here
    // TODO: check input is correct arity
    InitialContext ctx;
    boolean found = false;
    try {
      ctx = new InitialContext();
      MBeanServer server = (MBeanServer)ctx.lookup("java:comp/env/jmx/domainRuntime");
      ObjectName[] serverRuntimes = (ObjectName[]) server.getAttribute(domainRuntime, "ServerRuntimes");
      for (int i = 0; i < serverRuntimes.length; i++) {
        String serverName = (String) server.getAttribute(serverRuntimes[i], "Name");
        String serverState = (String) server.getAttribute(serverRuntimes[i], "State");
        if (((String)args[0]).compareTo(serverName) == 0) {
          // correct server
          if (((String)args[1]).compareTo(serverState) == 0 ) {
            // correct state
            found = true;
            break;
          }
        }
      }
    } catch (Exception e) {
      result.put(STATUS, FAIL);
      result.put(ERROR, e.getMessage());
      result.put(TRACEBACK, e.getStackTrace());
      result.put(RETURN, EMPTY);
      return result;
    }
    // create the response
    result.put(STATUS, found ? PASS : FAIL);
    result.put(ERROR, EMPTY);
    result.put(TRACEBACK, EMPTY);
    result.put(RETURN, EMPTY);
    return result;
  }

You can see that the same basic protocol is implemented here. The only different is in what we actually do in the business logic to come up with an answer. In this case, we look up the domainRuntime JMX MBeanServer, then go look for a server with the same name as the first parameter, and if we find it, we check if it’s state matches the second parameter. The we return a result based on what we found. Again, we should be more careful about our inputs existence and types, but you get the idea.

There is another keyword implemented that lets us check the state of an application. The data source keyword is not implemented, it is sitting there with just the protocol wrapper, but no logic. I thought you might like to have a go at implementing it

Following the keyword implementations, there are two more methods that we need to implement the protocol. Oh by the way, we are not implementing the full protocol here – just the basics. Let’s take a look at the get_keyword_names method:

  public String[] get_keyword_names() {
    // TODO: change this to use reflection?
    return new String[] { "ping",
                          "server_status_should_be",
                          "application_status_should_be",
                          "data_source_should_exist"
                        };
  }

Note that I am using the Python method naming standards here, since Robot is a Python-based framework. This method just needs to return an array with the name of the keywords that are implemented. I am doing this the lazy way – it would probably be better to produce the list with some kind of introspection, so you don’t forget to update it.

Finally, we need to implement the run_keyword method, which just routes the request to the right method to handle the keyword. Again, I have implemented this the lazy way, and there are certainly better ways to do it. Here is the code:

  public HashMap run_keyword(String keyword, Object[] args) {
    HashMap kr = new HashMap();
    try {
      // run the right method
      // TODO: change this to use reflection perhaps?
      if (keyword.equalsIgnoreCase("ping")) {
        kr = ping(args);
      } else if (keyword.equalsIgnoreCase("server_status_should_be")) {
        kr = server_status_should_be(args);
      } else if (keyword.equalsIgnoreCase("application_status_should_be")) {
        kr = application_status_should_be(args);
      } else if (keyword.equalsIgnoreCase("data_source_should_exist")) {
        kr = data_source_should_exist(args);
      } else {
        kr.put(STATUS, FAIL);
        kr.put(RETURN, EMPTY);
        kr.put(ERROR, EMPTY);
        kr.put(TRACEBACK, EMPTY);
      }
    } catch (Exception e) {
      e.printStackTrace(System.out);
    }
    return kr;
  }

So that completes our project, let’s go ahead and test it out. You can do that by just running

mvn verify

You should get some output like this:


C:\src\ci4fmw~robot\oracle-robot>mvn verify
 [INFO] Scanning for projects...
 [INFO]
 [INFO] ------------------------------------------------------------------------
 [INFO] Building oracleRobot 1.0-SNAPSHOT
 [INFO] ------------------------------------------------------------------------
 [INFO]
 [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ oracle-robot ---
 [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
 [INFO] skip non existing resourceDirectory C:\src\ci4fmw~robot\oracle-robot\src\main\resources
 [INFO]
 [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ oracle-robot ---
 [INFO] Nothing to compile - all classes are up to date
 [INFO]
 [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ oracle-robot ---
 [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
 [INFO] skip non existing resourceDirectory C:\src\ci4fmw~robot\oracle-robot\src\test\resources
 [INFO]
 [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ oracle-robot ---
 [INFO] No sources to compile
 [INFO]
 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ oracle-robot ---
 [INFO] No tests to run.
 [INFO]
 [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ oracle-robot ---
 [INFO] Packaging webapp
 [INFO] Assembling webapp [oracle-robot] in [C:\src\ci4fmw~robot\oracle-robot\target\oracleRobot]
 [INFO] Processing war project
 [INFO] Copying webapp resources [C:\src\ci4fmw~robot\oracle-robot\src\main\webapp]
 [INFO] Webapp assembled in [171 msecs]
 [INFO] Building war: C:\src\ci4fmw~robot\oracle-robot\target\oracleRobot.war
 [WARNING] Warning: selected war files include a WEB-INF/web.xml which will be ignored
 (webxml attribute is missing from war task, or ignoreWebxml attribute is specified as 'true')
 [INFO]
 [INFO] --- weblogic-maven-plugin:12.1.2-0-0:deploy (wls-deploy) @ oracle-robot ---
 [INFO] Command flags are: -noexit -adminurl t3://localhost:7001 -deploy -user weblogic -password ******* -name oracleRobot -source C:\src\ci4fmw~robot\oracle-robot\target\oracleRobot.war -targets AdminServer -stage -upload -verbose
 weblogic.Deployer invoked with options:  -noexit -adminurl t3://localhost:7001 -deploy -user weblogic -name oracleRobot -source C:\src\ci4fmw~robot\oracle-robot\target\oracleRobot.war -targets AdminServer -stage -upload -verbose
 <22/10/2013 7:40:08 AM EST>    
 Task 3 initiated: [Deployer:149026]deploy application oracleRobot on AdminServer.
 Task 3 completed: [Deployer:149026]deploy application oracleRobot on AdminServer.
 Target state: deploy completed on Server AdminServer

Target Assignments:
 + oracleRobot  AdminServer
 [INFO]
 [INFO] --- robotframework-maven-plugin:1.1:run (default) @ oracle-robot ---
 ==============================================================================
 Acceptance
 ==============================================================================
 Acceptance.Mytest
 ==============================================================================
 Ping Test                                                             | PASS |
 ------------------------------------------------------------------------------
 Server State Test                                                     | PASS |
 ------------------------------------------------------------------------------
 Application State Test                                                | PASS |
 ------------------------------------------------------------------------------
 Data Source Existence Test                                            | PASS |
 ------------------------------------------------------------------------------
 Acceptance.Mytest                                                     | PASS |
 4 critical tests, 4 passed, 0 failed
 4 tests total, 4 passed, 0 failed
 ==============================================================================
 Acceptance                                                            | PASS |
 4 critical tests, 4 passed, 0 failed
 4 tests total, 4 passed, 0 failed
 ==============================================================================
 Output:  C:\src\ci4fmw~robot\oracle-robot\target\robotframework-reports\output.xml
 XUnit:   C:\src\ci4fmw~robot\oracle-robot\target\robotframework-reports\TEST-acceptance.xml
 Log:     C:\src\ci4fmw~robot\oracle-robot\target\robotframework-reports\log.html
 Report:  C:\src\ci4fmw~robot\oracle-robot\target\robotframework-reports\report.html
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time: 26.213s
 [INFO] Finished at: Tue Oct 22 07:40:23 EST 2013
 [INFO] Final Memory: 39M/776M
 [INFO] ------------------------------------------------------------------------
 C:\src\ci4fmw~robot\oracle-robot>

So we can see that it all worked. And now we have a simple Robot Remote Library that we can extend as needed, and we can test it with Robot too. Enjoy!

A first look at Robot Framework

Mark Nelson — Sun, 15 Sep 2013 08:44:01 +0000

As we start to assemble the tools we need to implement Continuous Delivery, one area we need to look at is selecting a testing framework. Now, we are going to want to use a range of different testing tools, depending on what we want to test and how, but we ideally would have some kind of framework that helps to abstract those tools and gives us a single place to go to execute tests.

In looking for a test framework, I have been considering the following:

Preferably it should have some kind of backing to ensure its longevity and continued development,
Ideally I should not have to learn a new language to use the tool – since most Fusion Middleware users are already using Java and Python (for WLST scripts) – those two seem like the best choices,
It should be extensible, so I can add new types of test tools if I want to,
It should integrate well with Maven and Hudson, since those are already part of our ecosystem,
It should allow me to use a wide range of testing tools to execute the actual tests.

So after a bit of research, what I have come up with is Robot Framework. It is backed by Nokia Siemens Networks, it uses a simple text/table based test specification approach, Python and Java are supported for extension, there are Maven and Hudson plugins, and there are a wide range of plugins for many common testing tools like Selenium, Swing, iOS, Android, and support for OS integration (processes), XML, HTTP, SOAP, etc.

Seems like a good choice. So let’s take a look at it!

In this earlier post, we created a basic web application from the WebLogic Server ‘Basic WebApp’ Maven archetype. Let’s take that application and add some tests to it. We will do this using the Robot Framework Maven Plugin and the Selenium Library.

So the first thing we want to do, is add the Robot Framework Maven Plugin to our pom.xml by adding a new plugin element to the build section. Here is what we need to add:



  org.robotframework
  robotframework-maven-plugin
  1.2
  
    
      robot
      integration-test
      
        run

This tells Maven that we want to run the Robot Framework during the integration-test phase of the build. That is all the configuration we need. As with most things in Maven, there are a set of sensible defaults that we can follow to avoid any additional configuration burden. In this case, we will take advantage of two – the Robot Framework plugin looks for libraries in src/test/resources/robotframework/libraries and tests in src/test/robotframework/acceptance.

We are going to use the SeleniumLibrary. You can download the library from here. Inside the download you will find a directory called robotframework-seleniumlibrary-2.9.1/src/SeleniumLibrary. You need to copy that directory (i.e. SeleniumLibrary) into your project under src/test/resources/robotframework/libraries.

You can find documentation for this library here.

Now we can write a test. To do this, we just need to create a file in src/test/robotframework/acceptance. Let’s call it Basic_Test.txt. Here is how we specify the test using Robot Framework:

*** Settings ***

Library                             SeleniumLibrary
Test Set Up                         Start Selenium Server
Test Tear Down                      Stop Selenium Server

*** Test Cases ***

Basic Test
   Open Browser                     http://localhost:7001/basicWebapp/
   Page Should Contain              Basic Webapp
   Page Should Contain Textfield    j_idt10:name
   Page Should Contain Textfield    j_idt10:amount
   Page Should Contain Button       j_idt10:j_idt18
   Input Text                       j_idt10:name                            Fred
   Input Text                       j_idt10:amount                          39.99
   Click Button                     j_idt10:j_idt18
   Wait Until Page Loaded
   Page Should Contain              The money have been deposited to Fred, the balance of the account is 39.99
   Close Browser

Let’s take a look at how this test is specified. Firstly, you will see that the format is reasonably simple. Sections are marked with headings which start and end with three asterisks. This test has two sections:

Settings – tells Robot Framework about any libraries we want to use and any global actions to take. In this case, we want to use the SeleniumLibrary and we want to start the Selenium server before running the tests, and then stop it after all tests.
Test Cases – this section lists all of the test cases. In this example we only have one, called Basic Test, but we could have as many as we like listed here.

Test Cases are written using keywords. The keywords are the first thing on each line, for example Open Browser, Page Should Contain, and so on. After the keywords, there are (sometimes) parameters.

Robot tests are written in files like this. You do not actually have to line everything up in a table as shown here, the minimum is three spaces before the keyword and two spaces between the keyword and each parameter.

You can look up details of what each keyword does, and what others are available in the library documentation.

Keywords like Click Button take as a parameter something called a ‘locator’ – simply put these can be the id or name attributes of the HTML tag.

So this test will do the following:

Open a browser and go to the application
Check that the page shows up correctly
Fill in some data and take an action
Check that the expected outcome occured

To run the tests, all we need to do is execute Maven:

mvn verify

In the output you will see the tests running and output like this:


[INFO] --- robotframework-maven-plugin:1.2:run (robot) @ my-basic-webapp ---
==============================================================================
Acceptance
==============================================================================
Acceptance.Basic Test
==============================================================================
Basic Test                                                            | PASS |
------------------------------------------------------------------------------
Acceptance.Basic Test                                                 | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed
==============================================================================
Acceptance                                                            | PASS |
1 critical test, 1 passed, 0 failed
1 test total, 1 passed, 0 failed
==============================================================================

Robot also produces a report which you can view in your browser:

So that is a gentle introduction to Robot Framework. In future posts we will see how we can expand its usage to orchestrate complex acceptance tests, and how we can write our own keywords and extensions.

Enjoy!

SOA Development and Delivery

Mark Nelson — Wed, 01 May 2013 10:57:47 +0000

Let’s start by talking about what I mean by that. I don’t think that ‘SDLC’ is the right term to describe the space that I want to talk about, but it is a term that people are familiar with, so I think it makes a reasonable place to start. There are a lot of other terms that cover this space: governance, SDLC, development, version control, continuous integration, binary management, continuous inspection, continuous delivery, automation, virtualization, configuration management, devops, integration testing, and so on.

Also, by ‘SOA’ I really mean the broader set of technologies that we use to build ‘SOA Applications’ – whatever they are, and they are more than just composites. Real applications have many components, e.g. user interface, integration, mediation, rules, code, processes, forms, service definitions, canonical data and service models, and so on.

I don’t know about you, but I can’t think up a nice concise way to say that I mean all of those things across all of those technologies, so I am just going to call it ‘SOA Development and Delivery’ and I hope you will know what I mean.

The State of the Art

Recently, I conducted a survey, and I have spoken individually with many folks from all around the world, about how they do SOA Development and Delivery today, and how they hope to do it in the future. I think it would be fair to say that most SOA development today is not yet ‘industrialized’ – by that I mean that it is done by people of varying skill levels, working on a best effort basis, doing what they think is the right thing to do, and doing it the way they think is right.

By ‘industrialization’ I mean the development of standards, methods, processes, tools, and best practices, and the widespread automation of common tasks. Doing the right thing, and doing it the right way.

I think that we stand of the verge of a point of inflection in our industry where we will see SOA development and delivery become industrialized.

My feeling is that today, if I can generalize, that in terms of SOA development, people:

have adopted some kind of iterative, or possibly agile, development approach,
generally make some basic use of a version control system to manage source artifacts,
sometimes write unit tests, but don’t always check coverage or information content of those tests,
often try to automate the build process on a project by project basis,
generally do not try to apply any kind of quality control or inspection of their code base,
are maybe playing with or thinking about trying continuous integration,
have not recognized the need for binary management, or have, but gave up because it is too hard with the current state of tools,
generally try to use configuration plans (or equivalent), but often build binaries that contain topological information that is specific to a particular environment,
maybe have a governance process that is sometimes updated and sometimes followed,
don’t have a good way to manage dependencies between components,
use virtualization in their development and test environments, though perhaps not in concert with any type of automation,
don’t have a good way to manage test and development data sets,
have not adopted devops practices, and
do not have a repeatable way to execute tests and deploy the application to different environments.

The effect of all of this is that:

it is hard to estimate and plan SOA development projects,
projects often overrun their constraints,
often the delivered application is of poor or uncertain quality, and
build and deployment processes are very manual, time consuming, and error prone.

Pain all around – architects and project managers planning, developers and build engineers building, operations running, and of course the poor business customer who has to use the thing! Projects are delivered late, over budget, and erode the confidence of the business in the whole SOA promise and approach. So naturally, I asked myself, why is this the case? Well I think there are a number of contributing factors here:

the tools have not matured to a point that enables a lot of these things in a simple way,
there really aren’t any standards or reference architectures to follow,
some people don’t think of SOA development as ‘real’ development, and therefore don’t think these kind of practices apply to SOA development,
some of these are still maturing in the wild.

Conversely, it does not take a lot of time on Google to find a whole bunch of people who are interested in these areas and are clearly experimenting, prototyping, and sharing their experiences. And talking with folks who are actively engaged in SOA development, the clear, consistent message I hear is that all of this stuff is ‘really important stuff’ and we, as an industry, need it. It is also not hard to find consulting firms around the world that are developing capabilities and offerings in this space too.

So where do we go now?

Over a series of posts, I plan to share some thoughts and experiences on a range of topics, taken from those above, and also to share some practical examples of how to apply some of the state of the art tools and techniques from Java development to SOA development. In particular, specifically in the context of SOA/MDS/BPM/OSB/ADF, I want to talk about:

version control,
dependency management,
build automation,
continuous integration,
continuous inspection,
continuous delivery,
unit testing,
integration testing,
binary management,
environment provisioning,
configuration management,
customization (of binary artifacts to particular environments),
the ‘correct’ use of MDS, and
the relationship of SOA development and delivery to governance.

And I am planning to talk about tools like Subversion/git/gitlab, Maven, Hudson, Archiva/Artifactory, Sonar, Chef and many others.

I hope you join me on this journey, and please let me know your thoughts.

Testing Business Rules

Mark Nelson — Wed, 18 Apr 2012 12:10:26 +0000

Today I learned about a really neat utility that was developed by my colleague, Olivier Lediouris, which allows you to test Business Rules in a standalone/offline fashion – without the need to deploy them to a SOA/BPM server and build a whole composite around them.

Olivier describes it as:

A graphical user interface to test OBR without having to deploy anything anywhere.

You can find details and download the tool here. If you are using Business Rules, I would highly recommend checking this out.

Unit Testing Asynchronous BPEL Processes Using soapUI

Mark Nelson — Tue, 28 Feb 2012 04:11:42 +0000

This is a topic I have been interested in for a while. I have seen it done by some of my colleagues, especially in AIA environments, and I have been waiting to get an opportunity to work on it and document it.

But I recently found a great article from Daniel Amadei here. I strongly encourage you to take a look at it if you are at all interested in test automation and/or continuous integration.

I am planning to build this kind of testing into my continuous integration project here.