In addition to manual test cases and unit tests, Elastic Path relies on FIT (Framework for Integrated Test). FIT allows testers to write tests without writing any code. FIT is a good framework for use with EP because we usually have a set of defined business rules to which we know the expected results and outcomes.

What is FIT?

Originally developed by Ward Cunningham, FIT is based on JUnit. Unlike JUnit, which focuses on the functionality of one method, FIT is designed for testing components. For example, a typical JUnit test might check the calculation of shipping costs, whereas a FIT test would check the functionality of the entire checkout process, including selecting a customer, adding a product to the shopping cart, calculating the shipping costs, and completing the checkout process.

What does a FIT test look like?

A FIT test consists of a set of HTML tables that perform various tasks. This generally includes:

• initializing the data required for the test
• performing some actions
• checking the results of those actions.

The following is an example of a FIT test:

The test should always begin with a description of what the test is trying to accomplish. In this example, we are testing to see if adjusting inventory for a particular product works as expected.

The first table after the description points to a fixture. The fixture is a Java class that provides methods for use in the test. Every application that uses the FIT framework for testing has its own set of fixtures that are unique to its implementation. For example, the fixture that the test above references is PaymentServiceFixture. Therefore, we need a Java class named PaymentServiceFixture. Indeed, there is a class that exists with that name.

So where is all the data? That's in the next table:

When the test is run, this table tells the FIT framework to call the useScenario(String) method in PaymentServiceFixture or if not found there, in a superclass. In this example, the method resides in EpDoFixture, which is a superclass of PaymentServiceFixture.

How does FIT know to call a method named useScenario() that's expecting one parameter? It concatenates all the words in the odd cells in the table, removes the spaces, can captializes the first letter of each word after the first one. Therefore, in the example above, it is looking for a useScenario() method with one parameter inside it. (If the first cell of the method contains the keyword "check", the behavior is a bit different; it concatenates the contents of the even cells and tries to look for a getter method with that name.)

The useScenario(String) is a custom method in Elastic Path Commerce that attempts to parse the specified .scn file. The file actually contains another FIT test. We use these scenario FIT tests to help populate the data required to perform other tests. If we look in CA_Store.scn, we can see that there are mostly tables that aid in the set up of a store.

The next step after adding the common required data is to add the test-specific data. We should be adding inventories to the store. However, looking through the code in PaymentServiceFixture.java would not reveal to us that this method is available to use, since it is not one of the methods within that class. However, there is a method in CatalogSetUpFixture.java that does just that. We have another custom method in Elastic Path that allows us to call an operation in another fixture. We use the operation by the keyword "use", followed by the name of the fixture in the next cell. After we declare this in the first row of a table, we can then use methods of that class. Note that you can call any methods of the class as long as you have declared the class to use in the first row of the table.

The next step is to call the method addInventories(). Now imagine we have no idea what fields we need to populate this method. Let's go to the code to see what we need. Here is the code from CatalogSetUpFixture.java:

     /**
      * Action method <code>add inventories</code>.
      * 
      * @return <code>AddInventories</code> SetUpFixture
      */
     public SetUpFixture addInventories() {
          return new AddInventories();
     }

Because we know that addInventories() does not take in any parameters, all we need on the second row is just one cell, namely "add inventories". Here is what the table looks like at this point:

Still with me? Good. This part is going to get a little confusing, so pay attention. The addInventories() method returns a class of type Fixture, we can infer that there will be more rows in this table. But how do the row of tables look like? In order to answer this question, we have to go to the class AddInventories. In this class, we get the variables through a special method, whose name is a concatenation of the parameters it is expecting. As you can see from the following code, this looks pretty strange.

/**
      * SetUpFixture to add inventories.
      */
     public class AddInventories extends SetUpFixture {
          /**
           * Action method <code>product sku code warehouse code qty on hand reserved qty allocated qty</code>.
           * 
           * @param skuCode sku code
           * @param warehouseCode warehouse code
           * @param qtyOnHand qty on hand
           * @param reservedQty reserved qty
           * @param allocatedQty allocated qty
           */
          public void productSkuCodeWarehouseCodeQtyOnHandReservedQtyAllocatedQty(final String skuCode, final String warehouseCode,
                    final int qtyOnHand, final int reservedQty, final int allocatedQty) {
               Warehouse warehouse = warehouseService.findByCode(warehouseCode);
               catalogPersister.persistInventory(skuCode, warehouse, qtyOnHand, reservedQty, allocatedQty);
          }
 
          /**
           * Action method <code>product sku code warehouse code qty on hand reserved qty allocated qty reorder minimum reorder qty</code>.
           * 
           * @param skuCode sku code
           * @param warehouseCode warehouse code
           * @param qtyOnHand qty on hand
           * @param reservedQty reserved qty
           * @param allocatedQty allocated qty
           * @param reorderMinimum reorder minimum
           * @param reorderQty reorder qty
           */
          public void productSkuCodeWarehouseCodeQtyOnHandReservedQtyAllocatedQtyReorderMinimumReorderQty(final String skuCode,
                    final String warehouseCode, final int qtyOnHand, final int reservedQty, final int allocatedQty, final int reorderMinimum,
                    final int reorderQty) {
               Warehouse warehouse = warehouseService.findByCode(warehouseCode);
               catalogPersister.persistInventory(skuCode, warehouse, qtyOnHand, reservedQty, allocatedQty, reorderMinimum, reorderQty);
          }
     }

For this part, we need to separate that long method name into variable names. The order of the names must be the same as the order they appear in the method name. After this, the table should look like the following:

After we have all the variables split in to the correct format, we can add the data. We can add as many data rows as we want. Finally, table should look similar to the following:

The convention here is to color variables blue so that they stand out. The color properties are ignored by the FIT framework, so it is encouraged that you use colors for variables.

Validation

Now that we have added all the data neccessary for this test, we have to test whether or not the operation was successful. Here is the following table that does the trick.

Time for a quick quiz. What is the expected method name that we should see in PaymentServiceFixture.java? If you guessed inventorySummaryProductSkuCodeWarehouseCode(String, String), you're absolutely correct! This is the code in PaymentServiceFixture.java:

     /**
      * Checks inventory summary information.
      * 
      * @param skuCode product SKU code
      * @param warehouseCode warehouse code
      * @return <code>ParamRowFixture</code> parameterized with <code>InventoryDetailsRow</code> objects
      * @see <code>InventoryDetailsRow</code>
      */
     public Fixture inventorySummaryProductSkuCodeWarehouseCode(final String skuCode, final String warehouseCode) {
          ProductSku productSku = productSkuService.findBySkuCode(skuCode);
          Warehouse warehouse = warehouseService.findByCode(warehouseCode);
          Inventory inventory = productSku.getInventory(warehouse.getUidPk());
          return new ParamRowFixture(new Object[] { new InventoryDetailsRow(inventory) });
     }

The method returns a Fixture, which means another row in the table is required. But what does the next row look like? To find out, we need to look at the code into InventoryDetailsRow. We wrap the information into a row object. This is required by the FIT framework. Let's take a look at InventoryDetailsRow.java:

package com.elasticpath.fit.rowdata;
 
import com.elasticpath.domain.catalog.Inventory;
 
/**
 * Used in FIT tests as row representation of inventory details.
 */
public class InventoryDetailsRow {
 
     /**
      * Quantity on hand.
      * FIT field: qty on hand.
      */
     public int qtyOnHand;
 
     /**
      * Reserved quantity.
      * FIT field: reserved qty.
      */
     public int reservedQty;
 
     /** allocated quantity. */
     public int allocatedQty;
 
     /** available qty in stock. */
     public int availableQtyInStock;
 
     /**
      * Constructor fills the inventory details.
      * 
      * @param inventory the inventory
      */
     public InventoryDetailsRow(final Inventory inventory) {
          qtyOnHand = inventory.getQuantityOnHand();
          reservedQty = inventory.getReservedQuantity();
          allocatedQty = inventory.getAllocatedQuantity();
          availableQtyInStock = inventory.getAvailableQuantityInStock();
     }
}

The public fields in this class are the fields that we need in the FIT tables. They will determine the column names for the next row. In this case there are 4 fields: qtyOnHand, reservedQty, allocatedQty, and availableQtyInStock. We then add another row, which will contain the values that we expect the test to have. These fields also follow the concatenation convention, so you can either use the exact name of the field, or put spaces between each of the uppercase characters and use a lowercase letter instead. Notice that the backend for creating data and checking data is a bit different, even though in our FIT tables, it looks similar. This is because when we are checking data, FIT needs to validate the values in the table against the system, and it does so with row objects in this case. Finally, our last table looks like this:

If we run the test, this is what we will see in our results page:

Click on picture to enlarge

FIT is an invaluable testing tool for ensuring code quality and stability for the Product Development team. In addition to providing us with component tests, it ensures a measure of stability with our daily builds. After every build, our server runs all FIT tests in the system to make sure recent code commits don't cause any of the tests to fail. In that way, it acts as a source for regression testing. We've also recently started using FIT for acceptance testing. Since testers don't need to write code, they can write the tests (tables) in advance. Developers would then implement the fixture code after they have developed a new feature. A new feature is not complete until it passes all the FIT tests in that area. Finally, we are realizing other uses for FIT, including:

• Sample data population (using scenario data to build sample data, including catalogs, products, customers)
• Performance testing (creating batches of data and running the application under JProfiler to measure memory usage, CPU time, etc.)

Stay tuned for more detailed explanation on these two topics in another blog post!

Elastic Path supports web services via the Simple Object Access Protocol (SOAP), and provides support for obtaining and updating information for orders. The problem is, how do we actually test the web services component? One could write a custom SOAP client that interacts with the the SOAP server. However, there is an excellent tool available currently (and free) that can simulate sending a SOAP request, getting a response from the server, and then examining the data.

*Drum roll*

Introducing SoapUI. SoapUI is a Java-based program that aims to automate web service calls and can integrate into your testing framework. In this article we will go through the steps and create a test case that can be run automatically after the initial setup. We will introduce scripting in Groovy, a derivative of Java language.

The goal of this exercise to get used to the SoapUI framework and making a test suite consisting of updating a SKU, then checking to make sure that SKU has been updated. It can be run from the command line, and can generate reports/results, which could potentially be used in build reports.

To get started, you will need to have the following things ready:

1. SoapUI software. To get SoapUI, please visit http://www.soapui.org and get the latest version (at the time of writing, 2.5 is the most current version and will be used in this article)

2. The address of the Web Service Description Language file (WSDL). In this example the address is https://<your_domain>/webservices/catalogwebservice?wsdl where <your_domain> refers to the domain of your deployment

3. Permission priliveges to access web services. To create permissions you have to select the Web Service Role when creating a new CM user in the Commerce Manager client.

4. Have available SKU code information for use by the web services.

Step 1 - Creating a project

1. Open SoapUI, and then click on File->New soapUI Project.

2. In the Project Name text box, put in example1

3. In the Initial WSDL/WADL, type in the URL of the web service definition file (bullet number 2 in the previous section)

4. Press OK

    

   

A list of operations should appear on the left hand column. For the purposes of this demonstration, we will only test two operations, getSku and updateSku. Next, we will need to create a new TestSuite. Right click on the project name and then click on New TestSuite. Name it TestSuite 1 for the purposes of this test.

Now create a new TestCase by right clicking on TestSuite1 and click on New TestCase. Name it TestCase 1 for the purposes of this test.

Step 2 - Configuring the test case

The next step is to configure the test case so we can run the test. First we need to set the global settings. Click on the key icon and set the credentials for the username and password.

This username/password combination should match the user that has Web Services permission set in the Commerce Manager. Leave the Domain blank in this case.

The next step involves setting a property that can be accessed by the whole test case. Click on the Properties button.

Now add a property name called 'start' by click on the left-most icon. For the purposes of this test, we will name it 'date'. Give it a value of '2050-01-01T12:12:12.643-08:00'.

Step 3 - Adding the first SOAP request

We need to add a few SOAP requests first. Add the first SOAP request by clicking the little SOAP icon.

Name that request 'getSku', press Ok and click on CatalogWebServicePort->getSku from the dropdown box in the next dialog. Finish by clicking 'OK'. Now request window will open. Now on the left pane, the XML generated using the schema from the WSDL will be present. For this test case, use a SKU code that exists in the system and enter it in the <SkuCode> element. I chose '1YESPE' for this particular test. If you know the catalog that the SKU belongs to, put it between the catalog tag. Next we have add an assertion that the response is successful. We do that by clicking on the Assertions button and then clicking on the '+' button, then select 'Xquery Match' from the dropdown box. Fill in the details based on the values from below.

Press Save. By doing this, every time the test step is run, a validation check will occur. It will pass the check only if we see that the status of the test is succesful.

Queries using XPath are invaluable because they test can expected node values coming from the response. Since EP's Web Services returns a result status, it is ideal to evaluate the result using XPath queries. For more information on how to use XPath queries, please goto http://msdn.microsoft.com/en-us/library/ms256086.aspx

Step 4 - Adding the first Groovy script

SoapUI uses Groovy, an agile dynamic language for the Java platform. I won't go into details about Groovy, but basically if you know Java, then you know Groovy. To learn more about Groovy, please visit http://groovy.codehaus.org/.

For the first step of this part, you will need to add a test step to the test case. Right click on the test step on the left hand column and then click on Add Step -> Groovy Script.

A new window will appear. Fill in the following information in the box.

//gets the xml utilities

def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )

//get the reponse part

def holder = groovyUtils.getXmlHolder( "getSku#Response" )

//get the original start date

def startDate = holder.getNodeValue( "//StartDate" )

//assign it to a session variable to be used later

testRunner.testCase.setPropertyValue('temp', startDate);

//now update the Request of the second request

def holder2 = groovyUtils.getXmlHolder( "updateSku#Request" )

//gets the start date node and set it to our date

def startDate2 = holder2.setNodeValue( "//StartDate", testRunner.testCase.getPropertyValue('date'))

//update the change

holder2.updateProperty()

What does this do? Basically this will retrieve the startDate timestamp from the previous soap request and assign it to a variable, which will be used later at the end. This script also sets the variable of the next request so that it can be sent to the server. To read more on how to script your tests with Groovy in SoapUI, please visit http://www.soapui.org/userguide/functional/groovystep.html.

Step 5 - Configuring the rest of the test

Next we configure the rest of the steps. The rest of the test consists of:

Adding a SOAP request to update the SKU, and then checking the results.

1. For this request, we once again use assertions to help us identify potential problems. Create a new Xquery Match assertion and copy the data below into the boxes and press Ok.

Adding a Groovy script to retrieve the time stamp that was saved previously, and set it in the subsequent request.

1. This step is similar to the one before, and it will update the next SOAP request with original value that we retrieved (and saved) in the first request. The code is listed below.

    //gets the xml utilities

    def groovyUtils = new com.eviware.soapui.support.GroovyUtils( context )

    //now update the Request of the second request

    def holder = groovyUtils.getXmlHolder( "updateSku2#Request" )

    //gets the start date node and set it to our date

    def startDate = holder.setNodeValue( "//StartDate", testRunner.testCase.getPropertyValue('temp'))

    //update the changes

    holder.updateProperty()

Adding a SOAP request to update the SKU again, this time we replace the start date with the original date we retrieved from the first request (so that we don't have actually change any data in this test).

1. This step is identical to the previous updateSku request. We can actually make a clone of the last request and run that. The only difference is the value of StartDate, which actually will be changed by the Groovy script from above. To make a clone of the previous step, right click on the last SOAP request, and then click 'Clone TestStep'. Name the new step updateSku2.

Running the test case and making sure they pass

1. Run the test case by pressing the arrow button in the Test Case 1 window.
2. If you have done everything correctly, all the tests should be green when you run the test. Your screen should look similar to the following.

SoapUI is a powerful tool that is designed to test web services. It can be used as a functional testing tool, a regression testing tool and an unit testing tool. Furthermore, it has built in capabilities to run using command line and can generate reports after each run. This tutorial is just a fraction of the things that SoapUI can provide a QA team when it comes to testing web services.