Smoke Test v3

Major changes in Smoke Test for 3.0

Introduction

New 3.0 release of Openbravo ERP will include several changes from the 2.50 series. From the Smoke Test point of view, we have identified several updates required to get it working in the new release. This page will show the preliminar ideas used as a base for the product backlog

GUI

Information hiding

The components should be hidden from the interface, in a bottom-up approach. We will start with com.openbravo.test.integration.erp.modules.userinterface.smartclient.gui where we already created some base objects: Button, CheckBox and ComboBox These objects have a reference to the Smartclient-object's locator and they have basic methods like click, select, type and check.

A locator is a new feature designed for 3.0. Since this release will include SmartClient as a GUI framework, the traditional way to select objects in Selenium will not work. We developed a way to get the reference from a fixed place and the ERP will fill there the proper SmartClient dynamic locator.

Locators have the form: dom=window.OB.TestRegistry.registry['org.openbravo.client.navigationbarcomponents.QuitButton']

In case of simple objects, the implementation of each is a standard Selenium command (i.e. Button.type will be implemented as Selenium.type). For more complex types, underliying classes will execute any additional command (i.e. BusinessPartner.select("myCustomer") will perform all the required steps, including any related search required to properly select myCustomer)

Because of this approach, we could easly isolate the implementation from the business flows. In case a future release replaces SmartClient by a different library, we could easily identify the classes that are affected by the change. And main classes could remain as they were.

In order to achieve above statements, we assume a common design for all the components. That is, all the buttons could be grouped into a Button abstract class, all the combo boxes in the ComboBox class and so on.

What is pending to develop:

• Several new classes: textfield, radiobutton, table, etc
• Define if we allow nested objects. A Selector could be seen as a combo box plus a button with an icon and a text field to write. Will Selector class be a composite class (made of ComboBox, Button and TextField) or will implement its own methods?
• Some interfaces have to be defined in order to implement some methods, like Clickable, Writeable for the implementation of Click.
• How this will affect 2.50 smoke?

Bottom up design

Once the basic classes were defined, it will be possible to make more complex objects. Composing several ComboBox, one CheckBox and two Button, you could have a com.openbravo.test.integration.erp.modules.client.navigationbarcomponents.gui.UserProfile.ProfileTab object

File:UserProfile3.png

View larger

By doing so, we could go higer in the definition. The object com.openbravo.test.integration.erp.modules.client.navigationbarcomponents.gui.NavigationBar will have a QuickLaunch, a Menu and a UserProfile objects, each one composed of other objects as described above.

At the top, we will have a MainPage object, made of a NavigationBar and several Tab objects. Here is where differences are more evident regarding 2.50 smoke layout. In 3.0, all the objects will be hierachical, matching the GUI layout.

Delegation

As a natural consequence of having a hierarchy is the ability to delegate. That is, each component will perform the actions by letting their elements to perform the actions.

Starting with a Page object, an specific Page could be a Login object, where the user could provide the login credentials. MainPage that is the expected object after a successful login will check that Login was successful.

MainPage will have the ability to add new Tab objects. This will be done by calling the proper NavigationBar methods. For example:

quickLaunchView(view) { 
navigationBar.quickLaunchView(view);
}

With NavigationBar having a public method intended to delegate the method in the QuickLaunch object

quickLaunchView(view){
quickLaunchComponent.launch(view);
}

Finally, the QuickLaunch object, composed by a Combo will perform the Base actions:

launch(view){
button.click(); //Click the button to open the menu
combo.type(view): //Type the name of the window
waitforpagetoload; //The window is shown after typing it
}

That will make the design very clear, and the debugging of any run will give enough information to locate the exact point of a failure.

Open issues

• A detailed class diagram is required for better understanding.

Sample Code

This is how we plan to have the code for a generic test case once fully implemented

final LoginPage login = new LoginPage(selenium);
login.open(openbravoContext);
login.login(userName, password);

MainPage mainPage = new MainPage(selenium);
mainPage.verifyLogin(userName);

ClassicWindowView ModuleView =
   new ClassicWindowView(selenium, "Module");

mainPage.openView(ModuleView, mainPage.getNavigationBar()
   .getViewLauncher(QUICK_LAUNCH), "Module");
mainPage.verifyOpenView(items[items.length - 1]);
mainPage.logout();

login.verifyLogout();

Data

One of the most critical aspects of the Smoke Test (both current one and the 3.0 version) is how data is managed. Here, we aim to perform several changes in order to have more flexible data input

Data Composing

Currently, parameters are plain. For example, this is the test case header for create a Sales Order

public SAL0010_CreateStandardSalesOrder(String documentNumber,
   String transactionDocument, String businessPartnerKey,
   String invoiceFrom, String userContact, String priceList,
   String salesRepresentative, String formOfPayment,
   String paymentTerms, String productName, int orderedQuantity,
   String uomProduct, String unitPriceProduct,
   String listPriceProduct, String tax, String summedLineAmount,
   String grandTotalAmount)

This means all the parameters required for create a Sales Order has to be included at once, making the parameter list hard to read and maintain.

The plan is to move the parameters into Data Objects. A Data Object represents the data related with a Business Object.

A sales invoice will be represented as the fields required for filling the header, plus a SalesInvoiceLine object representing the line contents.

The method will look like:

public SAL0010_CreateStandardSalesOrder(String documentNumber,
   String transactionDocument, BusinessPartner businessPartner,
   SalesOderLine salesOrderLine, String summedLineAmount,
   String grandTotalAmount)

The parameters will be taken from an XML file, like this one:

<?xml version="1.0" encoding="UTF-8"?>
<testcase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="mySchema2.xsd">
<class>com.openbravo.test.integration.erp.gui.sales.transactions.SalesOrderHeader</class>
   <parameter>
      <name>documentNumber</name>
      <type>String</type>
      <value>SAL0010</value>
   </parameter>
   <parameter>
      <name>transactionDocument</name>
      <type>String</type>
      <value>Standard Order</value>
   </parameter>
   <parameter>
      <name>businessPartner</name>
      <type>com.openbravo.test.integration.erp.data.BusinessPartner</type>
      <value>
         <parameter>
            <name>businessPartnerKey</name>
            <type>String</type>
            <value>CUSA</value>
         </parameter>
         <parameter>
            <name>invoiceFrom</name>
            <type>String</type>
            <value>.Pamplona, Street Customer center nㆺ1</value>
         </parameter>
         <parameter>
            <name>userContact</name>
            <type>String</type>
            <value>Alfred</value>
         </parameter>
         <parameter>
            <name>priceList</name>
            <type>String</type>
            <value>Customer A</value>
         </parameter>
         <parameter>
            <name>salesRepresentative</name>
            <type>String</type>
            <value>Sales A</value>
         </parameter>
         <parameter>
            <name>formOfPayment</name>
            <type>String</type>
            <value>Money Order</value>
         </parameter>
         <parameter>
            <name>paymentTerms</name>
            <type>String</type>
            <value>30 days, 5</value>
         </parameter>
      </value>
   </parameter>
   <parameter>
      <name>SalesOrderLine</name>
      <type>com.openbravo.test.integration.erp.gui.sales.transactions.SalesOrderLine</type>
      <value>
         <parameter>
            <name>productName</name>
            <type>String</type>
            <value>FGA</value>
         </parameter>
         <parameter>
            <name>orderedQuantity</name>
            <type>String</type>
            <value>1</value>
         </parameter>
         <parameter>
            <name>uomProduct</name>
            <type>String</type>
            <value>Bag</value>
         </parameter>
         <parameter>
            <name>unitPriceProduct</name>
            <type>String</type>
            <value>2.00</value>
         </parameter>
         <parameter>
            <name>listPriceProduct</name>
            <type>String</type>
            <value>2.00</value>
         </parameter>
      </value>
   </parameter>
   <parameter>
      <name>tax</name>
      <type>String</type>
      <value>VAT(3)+CHARGE(0.5)</value>
   </parameter>
   <parameter>
      <name>summedLineAmount</name>
      <type>String</type>
      <value>2.00</value>
   </parameter>
   <parameter>
      <name>grandTotalAmount</name>
      <type>String</type>
      <value>2.07</value>
   </parameter>
</testcase>