View source | Discuss this page | Page history | Printable version   
Toolbox
Main Page
Upload file
What links here
Recent changes
Help

PDF Books
Show collection (0 pages)
Collections help

Search

ERP 2.50:Automated Testing/Packages Hierarchy

We have a namespace hierarchy defined by Java packages.

The top level testing package is com.openbravo.test. Every class related to Openbravo tests should be under this package.

Contents

Test type

In the next level we separate tests by its type. Currently our repository only includes a full integration testing (com.openbravo.test.integration). And there's also a prototype database unit testing (com.openbravo.test.dbunit). But in the future in this level we could find unit testing, load or performance testing, security testing, etc.

Software Product

After the test type comes the software product. Currently we only automate tests for the ERP (com.openbravo.test.integration.erp), but we here could add POS tests or any other product developed by Openbravo.

At this level we also store classes required to handle external software products used to perform the specific kind of test. For example:

Here we also store things that are common to multiple software products, like:

Test specifics

This packages of this level will be specific to the kind of tests being coded. The following are the packages specific for ERP integration testing.

Common classes

The package com.openbravo.test.integration.erp.common contains classes that are used by all ERP integration tests.

Data

Data objects are coded within this package: com.openbravo.test.integration.erp.data.

Data objects are the ones that group related attributes to form an entity. For example, the Location object has attributes for first line, second line, postal code, city, country and region.

This are then used as parameters for tests.

GUI

The GUI package (com.openbravo.test.integration.erp.gui) contains the definitions for all the ERP GUI elements.

We have two main types of GUI elements:

All the elements defined in this package extend from one of those two window types. And they are stored following the Openbravo ERP Menu hierarchy. For example, we have the classescom.openbravo.test.integration.erp.gui.applicationdictionary.Module and com.openbravo.test.integration.erp.gui.financial.receivablesandpayables.transactions.BankStatement. In these classes we define constants for the GUI elements inside of windows (textfields, checkboxes, lables, etc.) and functions that perform actions with those elements receiving parameters from test scripts (create a new record, edit a record, process and order, etc.)

In addition to those two we have other elements like window parts (Menu, MessageBox) and windows that are not part of the main ERP interface (Login).

Test scripts

Test scripts or test controllers specify the actions that have to be done on windows in order to complete a test.

This includes the steps, the verifications and the assertions that will tell if a test succeeded or failed.

So basically this classes are a sequence of instantiations of GUI windows and calling of functions of those windows passing variables as parameters.

In this package is stored OpenbravoERPTest, the base class that contains the methods called before the execution of the test to load properties like the Openbravo context, the speed of selenium, the browser where the tests are going to run and some other properties. After loading those values it starts selenium and the browser, transfers control to the specific test script and when the test is finished it captures a screenshot of errors (if present) and closes everything so the machine is ready to perform another test.

All the classes in this package are abstract and inherit from the class OpenbravoERPTest or (less frequently) from another abstract test script. And they must include at least one function with the @Test Junit annotation, i.e., the function that will be executed as an integration test on Openbravo ERP.

And the hierarchy here also follows the Openbravo ERP Menu hierarchy. But, as there may be test scripts that perform actions on more than one menu item, they must be stored under the package named after the menu item where the most important action is executed. We have for example com.openbravo.test.integration.erp.testscripts.generalsetup.application.modulemanagement.addmodules.InstallModuleFromFileSystem and com.openbravo.test.integration.erp.testscripts.generalsetup.security.user.CreateUser

Test suites

On this package (com.openbravo.test.integration.erp.testsuites) we store test suites and the scenarios with actual parameters.

Test suites are just classes with the Junit annotations @RunWith(Suite.class) and @Suite.SuiteClasses that group multiple scenarios.

Scenarios are classes that inherit from one of the abstract test scripts and that only include the values that will be passed as parameters to that test script in order to perform an actual test.

Parameters are a function that returns a collection of Object arrays annotated Junit's @Parameters. For example, the test scenario ADA0010_EditDocumentSequence inherits from the test script EditDocumentSequence and has the following parameters:

@Parameters
public static Collection<String[]> documentSequenceValues() {
	return Arrays.asList(new String[][] { { "AR Invoice", "1", "I/" } });
}

So, following this example, the test script EditDocumentSequence calls functions from windows in order to test an edition of a document sequence. The test script passes as parameters to those functions variables named documentType, nextAssignedNumber and prefix. And what this test scenario does is call the test script assigning the values "AR Invoice" as the variable documentType, "1" as nextAssignedNumber and "I/" as prefix.

The hierarchy inside this package follows testlink because, as explained on How to automate a test case, before automating a test it has to be documented there.

We have a subpackage called othertests to store tests that are not document on testlink. But before doing so it would be better to consult with a member of the QA team. And hopefully, the permanence of tests in this subpackage will be temporary.


Modules

There's a separate subpackage here for ERP modules tests: com.openbravo.test.integration.erp.modules.

So, if you are automating tests for Initial Data Load module for example, you should store them in com.openbravo.test.integration.erp.modules.initialdataload. And that package will have the same five packages inside:

Note: If you prefer, you can keep your module package in a separate Java project, and include a reference to the main ERP project to get the common classes that your tests will require.

Data access

At the fourth level we also have the classes used to access data storages that might be used in various kinds of tests, like databases. This package is named com.openbravo.test.dataaccess.

Retrieved from "http://wiki.openbravo.com/wiki/ERP_2.50:Automated_Testing/Packages_Hierarchy"

This page has been accessed 4,993 times. This page was last modified on 3 April 2012, at 11:00. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.