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:
- com.openbravo.test.integration.selenium: integration testing is possible thanks to selenium. This package contains classes to extend or encapsulate Selenium functionalities.
Here we also store things that are common to multiple software products, like:
- com.openbravo.test.integration.format: contains classes that convert strings to the format that the user will see. This might be required by ERP and the POS as well.
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.
- Test files: the functions of this class are used to access the testfiles folder (where csvs, logs, obx and other files are stored).
- Timeout constants: Constants used to wait for elements or conditions.
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:
- Windows (com.openbravo.test.integration.erp.gui.windows): for us, windows are the main section of ERP pages. They are accessed through the menu and can be form windows (for example, the Business Partners window, where you can see a grid with all Business Partners and create new ones, and there are other form windows as sub-tabs), process windows (for example, the one used to Set up the Initial Client) or 'tabbed windows (for example, the Module Management window, that has tabs for installed modules, add modules and installation history).
- Pop ups (com.openbravo.test.integration.erp.gui.popups): child windows of the browser. For example, the Role information pop up.
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:
- common (optional), for classes that will be used by all the tests in the module.
- data (optional), for the data entities in the module.
- gui, for the windows that the module adds to OpenbravoERP.
- testscripts, for the scripts that test the module.
- testsuites, for the scenario classes that specify the parameters of each test and the suites that group those scenarios.
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.