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

PDF Books
Add page
Show collection (0 pages)
Collections help


How to create testcases



This how-to will focus on creating a testcase making use of the Openbravo test base classes. The testcase will check that our system has at least one User with password. For this, we'll use the new DAL approach to access the database.

In computer programming, unit testing is a software design and development method where the programmer gains confidence that individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.[1]

All new developments must belong to a module that is not the core module. Please follow the How to create and package a module section to create a new module.

Preparing development environment

First of all you need to import src-test components of the Openbravo ERP. Follow the instructions described below.

Import into Eclipse IDE

Launch Eclipse.

Bulbgraph.png   After Eclipse has started go to Project menu and disable Build Automatically option there.

Now one new project need to be imported in the workspace (by menu File=>Import and then General=>Existing Projects into Workspace). Here they are:

OpenbravoTest    XXX\opensource\openbravo\erp\devel\main\src-test

Now, you are ready to work with test cases.

Creating the testcase

Just before starting

Test cases in OpenbravoTest

OpenbravoTest provides a set of unit tests, often called 'test cases' for things such as: runtime model consistency, data access layer features, webservices features, etc. This test cases are based on JUnit testing framework.

The set of tests you can find and study them in the project OpenbravoTest:

 |- ...
 |- ...
 |- src                <-- source of the testcases
 |- ...
 |- ...

Here is a direct link to the testcases in the code repository: Openbravo test cases.

Inheriting from OB BaseTest

All the core testcases are subclasses from OBBaseTest (org.openbravo.test.base.OBBaseTest). This class handles all the necessary steps to initialize the Data Access Layer, takes care of transaction handling and provides a set of utilities (methods) for working with the Openbravo context (OBContext).

Execution order of test methods

Until now, the methods were simply invoked in the order returned by the reflection API. However, using the JVM order is unwise since the Java platform does not specify any particular order, and in fact JDK 7 returns a more or less random order. Of course, well-written test code would not assume any order, but some does, and a predictable failure is better than a random failure on certain platforms.

Creating the Java class

 package org.openbravo.test.examples;
 import static org.junit.Assert.assertTrue;
 import java.util.List;
 import org.junit.Test;
 import org.openbravo.dal.service.OBCriteria;
 import org.openbravo.dal.service.OBDal;
 import org.openbravo.test.base.OBBaseTest;
 public class ExampleTest extends OBBaseTest {
  public void testUsersCount() {
    final OBCriteria<User> uCriteria = OBDal.getInstance().createCriteria(User.class);
    final List<User> uList = uCriteria.list();
    int userCount = 0;
    for (User u : uList) {
      if (u.getPassword().length() > 0)
    assertTrue(userCount > 0);
    System.out.println("Total of users with password: " + (userCount));

Understanding the class

You have just created a new class named Example that extends from the OBBaseTest class.

public void testUsersCount() {}

This class has a testUsersCount function. Note that all testing methods must start with test in the function name. e.g. testAllWarehouses(), testMyFirstTest(), etc


Sets the context as if a System Administrator is logged in the application.

Bulbgraph.png   There is a setUserContext(...) method to select running as another user, this method can be called in the middle of a testcase to switch user (if required)
final OBCriteria<User> uCriteria = OBDal.getInstance().createCriteria(User.class);
final List<User> uList = uCriteria.list();

Uses the OBDal instance to create a new OBCriteria object, and uses it for listing all (since we are not filtering) the Users in the database.

int userCount = 0;
 for (User u : uList) {
   if (u.getPassword().length() > 0)

We loop trough the uList collection, and we increment the userCount variable if the user has a password length > 0.

assertTrue(userCount > 0);

We assert that the userCount is more than 0.

 System.out.println("Total of users with password: " + (userCount));

Finally we print a total of users with password just for the record.

Transaction Handling

A question which might pop-up when looking at the above code: where is the database transaction handling done? The answer is that this is handled by the OBBaseTest class and the Openbravo data access layer:

The OBBaseTest class detects automatically if an exception happened or not.

There are certainly cases whereby it makes sense to have more control over the database transactions. There are a number of relevant methods which can be useful then:

Side-Effect Free

A test case will often change the data in the underlying database. Most of the time it is not feasible to setup a completely new test database for each test run. Therefore test-cases should be developed such that they are side effect free. This means:

This last point is important because there can be always reasons why during a test the clean-up step is not performed. For example because the test run is stopped before the clean-up is done.

Approach to new features of JUnit 4.11

Parameterized Tests

More info in: Parameterized-Test


More info in: Rules

Assertions and Hamcrest 1.13

Hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. There are a number of situations where matchers are invaluble, such as UI validation, or data filtering, but it is in the area of writing flexible tests that matchers are most commonly used.

When writing tests it is sometimes difficult to get the balance right between overspecifying the test, and not specifying enough (making the test less valuable). Having a tool that allows you to pick out precisely the aspect under test and describe the values it should have, to a controlled level of precision, helps greatly in writing tests.

More info in: Hamcrest

Ant Test Tasks

Openbravo has a number of ant tasks which run the test cases:

All the test cases are based on the Small Bazaar default data.

When adding new test classes to Openbravo ERP the developer has to always add the test class to the AllAntTaskTests test suite and if it is side effect free and quick to the AllQuickAntTaskTests and if it is side effect free but takes a bit more time to the AntTaskTests test suite.

The Result

To be able to execute your testcases:


Testing Requests

In general unit tests don't require of an Openbravo instance running in Tomcat to be executed. But in some cases, how requests work is wanted to be tested. Depending on the request to be tested, different classes should be extended:



Retrieved from ""

This page has been accessed 4,896 times. This page was last modified on 13 August 2014, at 12:19. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.