Wikiadmin: /* Run test located in external module locally */

2021-09-14T00:52:47Z

‎Run test located in external module locally

Wikiadmin: /* Run test located in external module locally */

2021-09-14T00:46:36Z

‎Run test located in external module locally

Wikiadmin: Created page with "== Objective == 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..."

2021-09-14T00:26:47Z

Created page with "== Objective == 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..."

New page

== Objective ==
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.<ref name="unittesting">http://en.wikipedia.org/wiki/Unit_testing</ref>

All new developments must belong to a module that is not the ''core'' module. Please follow the [[How_To_Create_and_Package_a_Module | 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.

{{(!) | 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:
<pre>
OpenbravoTest XXX\opensource\openbravo\erp\devel\main\src-test
</pre>

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 [http://www.junit.org/ JUnit] testing framework.

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

openbravo
|- ...
OpenbravoCore
|- ...
OpenbravoTest
|- src <-- source of the testcases
OpenbravoTrl
|- ...
OpenbravoWAD
|- ...

Here is a direct link to the testcases in the code repository: [https://code.openbravo.com/erp/devel/pi/file/8051c8a30e72/src-test/org/openbravo/test 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 ===
* Open your Eclipse IDE.
* Create a new folder structure under the ''modules'' folder: ''modules/org.openbravo.test.examples/src-test/org/openbravo/test/examples''.
* Add the newly created '''src-test''' folder to the ''Java sources'' on the project.
* Create a new Java class on the org.openbravo.test.examples package with the following content:

<source lang="java">
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.model.ad.access.User;
import org.openbravo.test.base.OBBaseTest;

public class ExampleTest extends OBBaseTest {

@Test
public void testUsersCount() {
setSystemAdministratorContext();
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)
userCount++;
}
assertTrue(userCount > 0);
System.out.println("Total of users with password: " + (userCount));
}
}

</source>

==== Understanding the class ====
You have just created a new class named Example that extends from the [https://code.openbravo.com/erp/devel/pi/file/8051c8a30e72/src-test/org/openbravo/test/base/OBBaseTest.java OBBaseTest] class.

<source lang="java">
public void testUsersCount() {}
</source>

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

<source lang="java">
setSystemAdministratorContext();
</source>

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

{{(!)|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) }}

<source lang="java">
final OBCriteria<User> uCriteria = OBDal.getInstance().createCriteria(User.class);
final List<User> uList = uCriteria.list();
</source>

Uses the [https://code.openbravo.com/erp/devel/pi/file/3d195dab015c/src/org/openbravo/dal/service/OBDal.java OBDal] instance to create a new [https://code.openbravo.com/erp/devel/pi/file/3d195dab015c/src/org/openbravo/dal/service/OBCriteria.java OBCriteria] object, and uses it for listing all (since we are not filtering) the Users in the database.

<source lang="java">
int userCount = 0;
for (User u : uList) {
if (u.getPassword().length() > 0)
userCount++;
}
</source>

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

<source lang="java">
assertTrue(userCount > 0);
</source>

We assert that the userCount is more than 0.

<source lang="java">
System.out.println("Total of users with password: " + (userCount));
</source>

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 [https://code.openbravo.com/erp/devel/pi/file/8051c8a30e72/src-test/org/openbravo/test/base/OBBaseTest.java OBBaseTest] class and the Openbravo data access layer:

* a transaction is automatically started at first database access in the test cases. This is done by the Data Access Layer.
* a transaction is either committed (when no exception happened) or rolled-back (when an exception happened).

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:

* OBBaseTest.commitTransaction: a convenience method which commits the transaction for you. This can be useful if you want to check if certain database actions result in exceptions in the database.
* OBDal.getInstance().flush(): flushes the update/insert queries in hibernate to the database.
* OBDal.getInstance().commitAndClose(): commits the transaction and closes the session. A new session/transaction is automatically started at the next database access.
* OBDal.getInstance().rollbackAndClose(): rolls back and closes the transactions. A new session/transaction is automatically started at the next database access.

{{(warn!)|[[How_to_implement_a_business_event_handler|DAL event observers]] are not triggered within test cases extending <code>OBBaseTest</code> class. They to work require of test cases extending <code>WeldBaseTest</code>. See [[#DAL_event_observers|this section]] for more information.}}

=== 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:

* When the test-case changes data then it should have a test method which is run as the last test method which cleans up/repairs the data.
* This clean-up method should also clean up data which is left from previous test runs.For this common issue should be used @AfterClass notation. This method runs automatically at the end of the class. More info in: [http://junit.sourceforge.net/javadoc/org/junit/AfterClass.html AfterClass-Notation].

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: [https://github.com/junit-team/junit/wiki/Parameterized-tests Parameterized-Test]

==== Rules ====
More info in: [https://github.com/junit-team/junit/wiki/Rules 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: [http://code.google.com/p/hamcrest/ Hamcrest]

=== Ant Test Tasks ===
Openbravo has a number of ant tasks which run the test cases:

* run.tests: the default, it runs the suite: ''org.openbravo.test.AntTaskTests''. These tests are side effect free and can be run multiple times, after the run the database should be in the same state as before.
* run.quick.tests: this task runs test cases which are fast and which test the most important parts of the system. It runs the test suite: ''org.openbravo.test.AllQuickAntTaskTests''.
* run.all.tests: runs the suite ''org.openbravo.test.AllAntTaskTests''. This suite contains all the test cases, also tests which can change the database.

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.

==== Skipping test cases ====
{{AvailableFrom|3.0PR17Q2}}
It's possible to define a list of test cases to be skipped. This is done by creating a file named <code>disabled-tests</code> in <code>config</code> directory. This file can contain a list of either fully qualified class names to be completely skipped and/or fully qualified class names followed by a "." and method name to skip individual test cases.

== The Result ==
To be able to execute your testcases:

* Right click on the ExampleTest class.
* Select ''Run AS > JUnit Test'' (Eclipse recognizes the class as a JUnit test because inherits from the JUnit OBBaseTest class).

[[Image:Testcases1.png|center]]

* You can check the result of the test case on the JUnit view:

[[Image:Testcases2.png|center]]

* And the output of your tests in the Console view:

[[Image:Testcases3.png|center]]

== 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:

*'''REST Webservices'''. <code>BaseWSTest</code> should be extended, it deals with authentication and provides methods to execute requests, parse xml results, etc.
*'''Other Requests''' (such as datasources). <code>BaseDataSourceTestNoDal</code> or <code>BaseDataSourceTestDal</code> classes can be extended (depending if the test case requires or not DAL). Similarly to webservices it provides authentication handling as well as utility methods to perform requests.

== Testing CDI ==

{{(!)|This feature is available since '''PR15Q4'''}}

Default test cases extending <code>org.openbravo.test.base.OBBaseTest</code> class cannot make use of dependency injection. In order to use it <code>org.openbravo.base.weld.test.WeldBaseTest</code> class needs to be extended instead. This is also a subclass of <code>OBBaseTest</code>, so it makes available all DAL infrastructure.

<code>OBBaseTest</code> uses internally [http://arquillian.org/ Arquillian] runner to create a Weld container.

Example of a test case injecting dependencies:

<source lang="java">
public class CdiInfrastructure extends WeldBaseTest {

@Inject
private ApplicationScopedBean applicationBean;

@Inject
private SessionScopedBean sessionBean;

@Inject
private RequestScopedBean requestBean;

/** beans are correctly injected */
@Test
public void beansAreInjected() {
assertThat("application bean is injected", applicationBean, notNullValue());
assertThat("session bean is injected", sessionBean, notNullValue());
assertThat("request bean is injected", requestBean, notNullValue());
}
}
</source>

=== Scopes ===

Application and session scopes are shared among all test cases in the same class whereas a new request scope is created for each test case method. Application scope is reset for each new class.

<source lang="java">
/** starts application and session scopes */
@Test
@InSequence(1)
public void start() {
applicationBean.setValue("application");
sessionBean.setValue("session");
requestBean.setValue("request");

assertThat(applicationBean.getValue(), equalTo("application"));
assertThat(sessionBean.getValue(), equalTo("session"));
assertThat(requestBean.getValue(), equalTo("request"));
}

/** application and session scopes are preserved but not request scope */
@Test
@InSequence(2)
public void applicationAndSessionShouldBeKept() {
assertThat(applicationBean.getValue(), equalTo("application"));
assertThat(sessionBean.getValue(), equalTo("session"));
assertThat(requestBean.getValue(), nullValue());
}
</source>

=== Parameterization ===

Because <code>CdiInfrastructure</code> class uses <code>org.jboss.arquillian.junit.Arquillian</code> runner, it is not possible to use other runners, which also includes <code>org.junit.runners.Parameterized</code> runner.

This limitation can be workarounded by adding a field annotated as <code>@Rule</code> with <code>org.openbravo.base.weld.test.ParameterCdiTestRule</code> type created with the list of the values for parameters and another field annotated as <code>@ParameterCdiTest</code> which will take those values. In this case each test case will be executed as many times as number of items the parameter list contains each of them the parameter field will take a different item.

<source lang="java">
public class ParameterizedCdi extends WeldBaseTest {
public static final List<String> PARAMS = Arrays.asList("param1", "param2", "param3");

/** defines the values the parameter will take. */
@Rule
public ParameterCdiTestRule<String> parameterValuesRule = new ParameterCdiTestRule<String>(
PARAMS);

/** this field will take the values defined by parameterValuesRule field. */
private @ParameterCdiTest String parameter;

private static int counterTest1 = 0;

/** Test case to be executed once per parameter value */
@Test
public void test1() {
assertThat("parameter value", parameter, equalTo(PARAMS.get(counterTest1)));
counterTest1++;
}
}
</source>

In this example <code>test1</code> test case will be executed 3 times having <code>parameter</code> field "param1", "param2" and "param3" value in each of these executions.

Unlike when using <code>Parameterized.class</code> runner, all these 3 executions are seen as a single execution (<code>Parameterized.class</code> would show 3 independent executions), this causes that if, for example, first execution fails the rest will not be run.

=== DAL event observers ===

Because [[How_to_implement_a_business_event_handler|DAL event observers]] make use of CDI to work, they are not executed in standard test cases extending <code>OBBaseTest</code>.

This limitation does not apply when using <code>WeldBaseTest</code> tests.

== Run test located in external module locally ==

When a test is created in an external module (external of OpenbravoTest project) some problems are found to execute the testcase in Eclipse. See an example of a test located in '''org.openbravo.client.myob''' module.

[[File:Before.png | 900px | center]]

As we can see in the previous picture, it is not possible to execute MyOpenbravoTest.java. The following actions will be done to be able to execute in local your testcase located in other module (external module of OpenbravoTest project):
* First of all, OpenbravoTest project should be configured properly. Steps:
** Copy classpahttp://wiki.openbravo.com/wiki/How_to_create_JUnit_testcases#Run_test_located_in_external_module_locallyth: ~/pi/src-test$ cp .classpath.template .classpath
** Import in eclipse project folder ~/src-test
** Full documentation can be found in the previous sections of this page.
* Right click on OpenbravoTest project.
* Select Properties > Java Build Path.
* Click on ‘Link Source’ button.
* Fill the ‘Linked folder location’ field with the src-test folder of the target module. (e.g. openbravo-path/modules/org.openbravo.client.myob/src-test).
* Click on ‘Apply’ button.

Now it is possible to execute a test located in external module locally. See the image below.

[[File:After.png | 900px | center]]

[[Category:HowTo]]

@@ Line 311: / Line 311: @@
-[[File:900px-Before.png | 900px | center]]
+[[File:Before_900px.png | 900px | center]]
@@ Line 328: / Line 328: @@
-[[File:900px-After.png | 900px | center]]
+[[File:After_900px.png | 900px | center]]
 [[Category:HowTo]]

@@ Line 311: / Line 311: @@
-[[File:Before.png | 900px | center]]
+[[File:900px-Before.png | 900px | center]]
@@ Line 328: / Line 328: @@
-[[File:After.png | 900px | center]]
+[[File:900px-After.png | 900px | center]]
 [[Category:HowTo]]

How to create JUnit testcases - Revision history

Wikiadmin: /* Run test located in external module locally */

Wikiadmin: /* Run test located in external module locally */

Wikiadmin: Created page with "== Objective == 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..."