Tuesday, February 18, 2014

How To Write Your First Greg Integration Test In New WSO2 Test Framework 4.3.0 .....

In this documentation I am going to explain how to write a simple GREG integration test.

Objective :

We will illustrate how to write a test to add schema to greg server and verify the existence of the added / uploaded schema  to the server.  

Note : you can start writing your tests in the following location according to your greg server version :



Steps to  follow :

Refer below table  where I have created SchemaUploadTestCase.java in a more common form for illustration purposes only.


package org.wso2.carbon.registry.addresources.test;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;
import org.wso2.carbon.authenticator.stub.LoginAuthenticationExceptionException;
import org.wso2.carbon.automation.api.clients.registry.ResourceAdminServiceClient;
import org.wso2.carbon.automation.engine.context.AutomationContext;
import org.wso2.carbon.automation.utils.registry.RegistryProviderUtil;
import org.wso2.carbon.governance.api.schema.SchemaManager;
import org.wso2.carbon.governance.api.schema.dataobjects.Schema;
import org.wso2.carbon.registry.app.RemoteRegistry;
import org.wso2.carbon.registry.core.Registry;
import org.wso2.carbon.registry.core.exceptions.RegistryException;
import org.wso2.carbon.registry.handler.stub.ExceptionException;
import org.wso2.carbon.registry.resource.stub.ResourceAdminServiceExceptionException;

import javax.activation.DataHandler;
import javax.xml.xpath.XPathExpressionException;
import java.io.File;
import java.io.IOException;
import java.net.URL;
import java.rmi.RemoteException;

import static org.testng.Assert.assertTrue;

public class SchemaUploadTestCase {

   private static final Log log = LogFactory.getLog(SchemaUploadTestCase.class);
   private AutomationContext automationContext;
   private ResourceAdminServiceClient resourceAdminServiceClient;
   private RegistryProviderUtil registryProviderUtil = new RegistryProviderUtil();
   private  SchemaManager schemaManager;
   private String schemaId;

   private Registry governance;

   @BeforeClass(groups = {"wso2.greg"})
   public void init() throws Exception {     // 01
       automationContext = new AutomationContext("GREG", "lbw001", "superTenant", "superAdmin");
       int userId = 1;
       RemoteRegistry registry = registryProviderUtil.getRemoteRegistry(userId, "GREG");
       governance = registryProviderUtil.getGovernanceRegistry(registry, userId);
       resourceAdminServiceClient = new ResourceAdminServiceClient(getBackendURL(),getSessionCookie());

   public void DeleteLCResources() throws GovernanceException {
     schemaManager.removeSchema(schemaId); // 07

   @Test(groups = {"wso2.greg"}, description = "Add new schema")
   public void addSchema() throws IOException, ExceptionException, RegistryException, ResourceAdminServiceExceptionException {

       String resourceLocation = "xxx/xxx/xxx/xxx";
       String filePath = resourceLocation +
               File.separator + "schema" + File.separator + "calculator.xsd";

       DataHandler dh = new DataHandler(new URL("file:///" + filePath)); // 04

       resourceAdminServiceClient.addSchema("Adding My Schema",dh);

       SchemaManager schemaManager = new SchemaManager(governance); // 05
       Schema[] schemas = schemaManager.getAllSchemas();
       boolean resourceFound = false;
       for (Schema schema : schemas) {
           if (schema.getQName().getLocalPart().equals("calculator.xsd")) {
               resourceFound = true;
               schemaId = schema.getId();
               log.info("Schema ID is : "+ schemaId);

      assertTrue(resourceFound, "Schema Not Found"); // 06

   private String getBackendURL() throws XPathExpressionException {   // 02
       return automationContext.getContextUrls().getBackEndUrl();

   // 03
   private String getSessionCookie() throws LoginAuthenticationExceptionException, XPathExpressionException, RemoteException {
       return automationContext.login();

Description :
Prerequisites :

You need to place the schema to be uploaded to the server inside the resourceLocation.

resourceLocation = "/home/xxx/svn/platform/branches/turing/products/greg/x.x.x/modules/integration/registry/tests-new/src/test/resources/artifacts/GREG/”

01. Create a method called init() and initialize an automationContext object. Pass relevant parameters in accordance with the given values of the automation.xml.

02 & 03 .  Now you can derive the backendservice urls and session cookies as shown in  getBackendURL() & getSessionCookie() methods.

Create instances from ResourceAdminServiceClient & RegistryProviderUtil classes as you may need these instances to add the schema to the server. Note the parameters needs to pass when creating an instance from ResourceAdminServiceClient.

Now start writing your test scenario under @Test annotation. Create a DataHandler from the schema resource file as shown in step 04 and invoke the addResource(...) method of the resourceAdminServiceClient to add / upload the schema to the server.

05 shows the steps involved in verifying the schema added to the server. In here by calling an instance from the  SchemaManager class I can seek for the schema uploaded and if the schema was successfully uploaded assert statement shown in 06 will not encounter a failure.

@AfterClass you can remove the added schema as shown in 07 by invoking removeSchema(...) method using schemamanager instance.

Thats all. You can now start writing numerous testing scenarios using SchemaUploadTestCase .java as a template / guidance.

Monday, February 3, 2014

The main purpose of the DistributionValidationTest.java class is to validate contents inside a product distribution. This post will illustrate the main aspects of distribution validation test class and some related information.


There are seven major distribution validation aspects being covered from  DistributionValidationTest.java class. These are,

1.Validation of jar files inside the product distribution against the LICENSE.txt.
2.Recursive scan to find the occurrence of SNAPSHOT keyword in file names and contents of textual files( eg : .txt, .xsd, etc).
3.Validate duplicate .jar entries inside the  LICENSE.txt  file.
4.Check whether maven variables are properly replaced inside configuration files found in
repository/conf directory.
5.Validate product distribution size against the latest released distribution in the maven repo
6.Identification of duplicate jars inside the distribution pack.
7.Product specific checks - validate sample directory - versions, resources validation

** There are several distinct test cases being developed to cover above major aspects and based on the findings/outputs under each category a summarized report will be generated with all the information included.  You can navigate to .. /target/DistributionValidationTestReport.txt to find the report.


  • XSD (XML Schema Definition) files for configuration files (eg: carbon.xml , axis2.xml) inside repository/conf.  - You can generate these schemas using on-line XSD generators.
  • Latest released version of the product distribution being hosted in maven-repo.


1. Validation of jar files inside the product distribution against the LICENSE.txt
           - The implemented test case is capable of identifying the .jar files which resides inside the xxx/repository/components/plugins directory against .jar file names mentioned in the carbon_home/LICENSE.txt file.  Firstly it will derive all .jar file locations inside the plugins directory and match these against the LICENSE.txt file to identify missing jars.  

2. Recursive scan for occurrence of SNAPSHOT keyword in file names and contents in textual files (.txt, .xml, etc).
           - The test will perform a recursive scan in-order to identify occurrences of the keyword “SNAPSHOT” inside the textual files and in their names. If an occurrence/s found the test will encounter a failure at the relevant assert statement.

3. Validate duplicate entries in LICENSE.txt file.
           - Test case will search for duplicate  .jar file names (If the same name is appearing more than once) in the LICENSE.txt file. These file names will be stored using a collection interface and finally the test case will output these .jar file names to the report.

4. Checking whether Maven variables are properly replaced inside configuration files found inside repository/conf
          - The test case will check for maven variable replacements by performing xml schema validation techniques. The user of the test case need to provide the xsd (XML Schema Definition) files of corresponding xml’s need to be checked. Mainly the test case will focus on the ’ $ ’ marks (these are the tags expected to update at the build time) in the XSD files and validate the relevant XML file for updation of each tag attribute value.

5. Validate product distribution size against the latest released distribution in the maven repo
         - The intention of this test case is to validate the running distribution size against the latest released distribution pack’s size. The test case will access the relevant maven repo and seek for the latest distribution hosted in it. Next It will retrieve the size of the distribution hosted and evaluate it with the running distribution’s size.
(Note: you need to make sure once a released been done , the distribution pack should be hosted in the repo. Size comparison will be based on pre-accepted value range for all wso2 products.

6. Identification of duplicate jars inside the distribution pack.
        - Test case is designed using a special regular expressions to derive the version of every .jar file and identification of duplicate .jars inside the pack. Based on the findings of the test case .jar file locations will be printed in the report file under two categories namely,  duplicate jar files in the same directory and with different versions inside the distribution.

7. Product specific checks for whether samples/resources are properly packaged
           - For this purpose the test case will perform some specific scans inside each samples directory and verification will be carried out to confirm that top most level sample directories does not carry any versions with their names. In addition the test case is capable of identifying k whether samples directory (if exists) has a README.txt/pom.xml/build.xml at the same level where src directory exists and to check whether resources directory (inside the src) contains any files.