Storefront Test Automation Engine

The Storefront Test Automation Engine facilitates the process of writing, maintaining, and running test scripts.

Prerequisites

Ensure that your store is using development best practices. For more information about coding JSP pages, see Best practices: Coding JSP pages to use the Storefront Test AutomationEngine.

The following diagram describes the Storefront Test Automation Engine components:

A description of the Storefront Test Automation Engine components.

Test suite

Test Suites are built based on JUnit 4 and are used to select the test case that must be run. You can read the JUnit documentation on how to create a test suite and how to add test classes and test cases to a suite.

Example
 /**
 *  Test suite to run all test scenarios in the Aurora-Tests-Wte project.
 */
public class AllTests{
   public static junit.framework.Test suite(){
      TestSuite suite = new TestSuite();
      suite.addTest(new JUnit4TestAdapter(FSTOREB2C_00.class));
      suite.addTest(new JUnit4TestAdapter(FSTOREB2C_01.class));
      suite.addTest(new JUnit4TestAdapter(FSTOREB2C_02.class));
      suite.addTest(new JUnit4TestAdapter(FSTOREB2C_04.class));
      suite.addTest(new JUnit4TestAdapter(FSTOREB2C_05.class));
      return suite;
   }
}

Or

Example #2
 /** 
* Test suite to run all sanity test scenarios in the Aurora-Tests-Wte project. 
*/
@RunWith(Categories.class)
@IncludeCategory(Sanity.class)
@SuiteClasses({FV2STOREB2C_00.class,      
      FV2STOREB2C_01.class,      
      FV2STOREB2C_02.class,      
      FV2STOREB2C_04.class,      
      FV2STOREB2C_05.class,    
    })
public class SanityTests {       
        // Sanity Test suite
}

Test

A Storefront Test Automation Engine test performs a few tasks from different page objects to test a storefront flow.

Since all tests are built by using JUnit version 4, all methods must match the following criteria to be identified as a test:
  • Be annotated with @Test annotation
  • Be public
  • Have no arguments

Methods that are annotated with @Before are called before each test case. They are used to prepare the data that is required by the test.

Methods that are annotated with @After are called after each test case. They are used to release resources after a test is complete or complete a cleanup. For example, you can use it remove products from cart, or delete existing wish lists.

Tip: Keep the test method code simple and easy to follow. Encapsulate complex logic in reusable tasks.
Example:
	 /**
	 * Test case to login to AuroraEsite with valid user id and password.
	 */	
	@Test
	public void testFSTOREB2C_0201()
	{
		//Open Auroraesite store
		AuroraFrontPage frontPage = getSession().startAtPage(getConfig().getStoreUrl(), AuroraFrontPage.class);	
		
		//Click on the SignIn page link on the header
		SignInPage signInPage = frontPage.getHeader().signIn();
		
		//Enter a valid username
		signInPage.typeUsername(dsm.getInputParameter("STORE_USER_NAME"))
		
		//Enter a valid password
		.typePassword(dsm.getInputParameter("STORE_USER_PASSWORD"))
		
		//Click Sign In
		.signIn();					
	}

Store page objects

Store page objects are Java classes that act as a high-level abstraction of the web page, or a section of the web page. They include relevant tasks and the element identifiers found on the web page that is used by the tasks.

Using the Page Object Pattern, each store or widget (section of a page) task returns the end page or widget that it would land on in a stable state. The framework returns the next page object and verifies that the page fully loaded, is stable and that it is the expected page before it continues running the script. For example, a task that clicks the sign-in link returns the sign-in drop-down widget. The sign-in drop-down widget is stable and ready to perform all the tasks that you can do in it.

public SignInDropdownWidget signIn() 
{  
getFactory().createQuery(SIGN_IN_LINK).withinAjaxTimeout().executeForOne().click();  

return getFactory().createPage().build(SignInDropdownWidget.class); 
}

All the elements that are used by the tasks are defined in the page object. They can be defined as an ID, class, XPath, link text, and so on. For example:

private static final Identifier shopcartWidget = Identifier.byId("widget_minishopcart");

The PageFactory class interacts with pages and elements on the page, including finding elements, clicking, typing, and instantiating the next page that is returned by the tasks.

Web test engine

This layer offers functionality to the tests to interact with a web browser. It abstracts the tests from the test tool that is being used. See the classes in com.ibm.commerce.qa.wte.framework.page in the Storefront Test Assets Javadoc for details on how to use this tool.

Selenium

Selenium WebDriver is an open source tool that you can use to automate web browser interactions. Selenium WebDriver makes direct calls to the browser by using each browser’s native support for automation. It does not require a Selenium server to execute test cases.

The Storefront Test Automation Engine automatically starts the Selenium WebDriver on the local machine during test execution.

Server API calls

The Storefront Test Automation Engine contains a lightweight server API calling mechanism that interacts with the WebSphere Commerce Server. It is built on top of HTTP Client to create HTTP requests and to read HTTP responses. It is used to call WebSphere Commerce Accelerator by loading the HTML page. It is also used to call Management Center by calling the Services.

Note: You can also make the tests invoke the WebSphere Commerce services by using the services client stubs packaged within the development toolkit.