Welcome!

Java Authors: Dana Gardner, Pat Romanski, Elizabeth White, Frank Huerta, Pieter Van Heck

Related Topics: Java, SOA & WOA, Open Source, Eclipse

Java: Article

OSGi Application Testing with Tycho

A detailed tutorial

The OSGi framework is a popular platform for developing multifunctional desktop systems, enterprise systems and complex applications.

OSGi uses a modular approach where each bundle is regarded as a relatively independent and separate unit. The framework controls maintenance-based tasks such as managing interactions between bundles, resolving dependencies, and managing lifecycles. Therefore, programmers can reallocate their time with less routine work and concentrate solely on solution development.

However, testing such applications is a real problem. It is more demanding than regular Java application testing: there is a need to test interactions between the bundles, and the tests must occur within a real environment. In this case, the test must run inside the OSGi platform; thereby creating the need for specialized test frameworks.

The article focuses on OSGi application testing solutions based on the Tycho Project and Pax Exam. It provides a detailed tutorial with examples.

Actual Experience with Pax Exam
Creating a complex project from scratch that included development of an OSGi-based enterprise platform, we sought a specialized testing framework that effectively examines application functionality.

We were using Eclipse as the IDE for application development. Initially our tests were created as a JUnit Plug-in Test, which is a part of Eclipse. This approach is very helpful for developers because it allows tracking of problems and errors during the development process right after code is changed. Eclipse traces all changes on the fly without any additional manipulations; this data is presented in the test results. In addition, testing runs within the OSGi environment.

The aforementioned approach has one critical disadvantage: tests run only within Eclipse. We used Maven2 as the open source build tool and Hudson CI as the automated build monitoring system. There was no way to use tests with Maven, but we strongly needed test automation.

We quickly discovered that this area was not well established (see http://java.dzone.com/articles/dozen-osgi-myths-and) as only two specialized testing frameworks for the OSGi Platform functional existed: Pax Exam and Spring-DM. Pax Exam, based on JUnit4, was the only appropriate choice for us (Spring-DM is based on JUnit3).

We used Pax Exam over a year and faced a number of issues related to test development, running test suites, and sharing test results. We created a number of workarounds, but some issues were still irresolvable due to framework limitations.

We started with version 1.2.0 and finished using version 1.2.2, the latest available update at the time. Pax Exam gave us the ability to create integration tests using JUnit. The test for Maven was created as a Maven plugin. How does it work? It starts the OSGi platform, installs bundles necessary for testing, wraps the test in temporary OSGi bundle and installs itself in the OSGi platform. The test is able to use and check bundles within OSGi. You just need to configure the plugin in pom.xml and set configurations for each test. The bundle list can be set using paths on file system, using URLs or using artifacts from the Maven repository. (See the user guide)

This was the cause of our first difficulty. There was no way to set a bundle list as Maven dependencies, an approach which could have  independently resolved all bundle dependency issues. Instead, Pax Exam tests required links to the file system or the Maven repository. This method for bundle dependencies resolution had the following advantages and disadvantages for our project:

  • All bundles for testing had to be built and ready before test execution. This required testing from the application building process.
  • Separated build and testing processes made the build and automation process more complex
  • Dependency management was not easy to use
  • The advantages were similar: as long as the Maven repository contained build bundles, then a user could run testing processes independent from the main application building process; an application's source code was not required.

The main problem for us was the absence of an easy-to-use test framework inside Eclipse. We could run tests from Eclipse using the Eclipse Maven plugin; results were processed and shown as a regular JUnit test. However, it was the same as running tests with Maven from the command line. Eclipse workspace did not affect tests. For those using Pax Exam desiring to run tests from Eclipse after changing the testable code, one must perform several actions. First, one must build/install all necessary bundles which are changed. Second, one must clean the project with tests. Only once these steps are completed can a test be run. For our application some parts took up to two minutes for complete building. At the same time Eclipse refreshed and rebuilt the same project in seconds. It was very inconvenient to perform these time-consuming procedures for changing one line of code. This created many errors and problems during development.

We found that Pax Exam runs the test as a separate Java process. As a result, a remote debugger had to be used, which was more complex than regular debugging. On the other hand it was not enough to stop the test from Eclipse or terminate Maven execution should a test need to be cancelled. One must terminate the appropriate Java process. Moreover, Pax Exam was limited since it cannot run two or more simultaneous tests.

However, Pax Exam has a feature which was important for our tests. It runs each test method inside a separate OSGi environment; this guarantees that all tests run independently and isolated. Of course, this feature has a side effect - execution time.

Tests used files/resources during execution. It was helpful that Pax Exam allowed our programmers to set a working directory for each test.

Finally, difficulties arose due to the fact that the test project was not a regular OSGi bundle; thus, it was impossible to control dependencies. We needed to use third party libraries in several tests, but testable bundles did not use or provide them. With the OSGi bundle one can include it to a bundle's class path. But we were unable find a way to do so for the Pax Exam tests. We had to create special bundles for support which provided necessary libraries for tests.

In spite of all the disadvantages of the described framework for our project, we used it successfully for more than a year and it resolved our tasks. Pax Exam constantly updates and improves.

Tycho as a Solution for Test Development
The Tycho Project is an approach to building OSGi bundles, Eclipse plug-ins, and so on. Tycho is currently in the Incubation Phase.

In November 2010 we decided to use the Tycho Project and Maven 3 for the entire project because these technologies radically simplify the building process. This was a great opportunity to use the advantages of Tycho for testing. Eventually, we resolved almost all limitations and difficulties related to Pax Exam. After migrating our tests to Tycho, the development process became easier and faster.

Briefly, Tycho runs tests the same way as Eclipse runs JUnit Plug-in tests, but from Maven. Generally, the testing approach with Tycho has no differences from the testing approach with Pax Exam. We also had a separate project with tests. But in the Tycho case, it was real OSGi bundle with manifest which contained main configuration and dependencies. This contrasts Pax Exam which uses pom.xml for same aims.

I should start with the fact that the migration process from Pax Exam to Tycho did not take a long time nor did it create any difficulties. It was quite simple. The main problem was the following: in contrast to Pax Exam, Tycho does not start a separate OSGi platform for each test, but runs all tests inside one OSGi environment. This was the source of many errors and conflicts in tests because we relied on a ‘clean' system for each method. We were forced to reinitialize the application before every test. Nevertheless, we found new problems related to improper termination of some application components. For example, HTTP or JMS servers which were started for one test could affect another test.

However, this method had an advantage- execution time. Execution time was decreased from four hours to one hour. We removed a workaround related to constant hangs during test execution and disregarded the problem.

We found that many disadvantages of Pax Exam for our project were solved with Tycho.

One of the main advantages of Tycho is that testable bundles are set as dependencies in the manifest of the project with tests. They are resolved using Maven. There is no need to define links to prepared bundles from the file system or in the Maven repository. Moreover, there is no need to separate the testing and build processes. Testing became a part of the main build process and Maven resolved all dependencies to testable bundles on the fly. The test project became more accurate, more logical and simpler.

In regards to project with OSGi bundle tests, one can add any third party library in one's class path and use it within the test. This allowed us to remove special separated bundles which provided necessary libraries for tests which we created when Pax Exam was used.

The main problem for us - using tests from Eclipse IDE - was solved. All tests were JUnit Plug-in tests and run easily. There was no need to do several Maven operations before running a test. Eclipse resolved all dependent projects from workspace instead of using the Maven plugin. Any change in workspace affected tests immediately.

One more advantage I want to mention is that Tycho allows running several tests in one time and it does not start separate Java process for each test; thereby, simplifying test debugging, starting and stopping.

Tycho supports target platforms, similar to Eclipse IDE, which was very necessary for us.

In summation, Tycho simplified and sped up development, debugging, automation, and the process of finding and fixing bugs. The approach itself seems more elegant, clear and appropriate for our aims.

Tutorial. Testing with Tycho
The following tutorial will show you how to create a simple OSGi bundle in Eclipse and create JUnit Plug-in tests. You also learn how to build and test created application with Tycho.

Prerequisites
This tutorial assumes that you have installed Java 1.6, Eclipse 3.6 and Maven3 and have a basic understanding of Java, OSGi and Maven.

OSGi Bundles
We are going to create simple OSGi bundles. See the detailed tutorial related to OSGi http://www.vogella.de/articles/OSGi/article.html .

Create a new plugin projects "com.axmor.osgiexample.providera" and "com.axmor.osgiexample.providerb". Both of these bundles will provide simple service that returns current prices for companies A and B:

Activator.java
package com.axmor.osgiexample.providera;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

private static BundleContext context;

static BundleContext getContext() {
return context;
}

public void start(BundleContext bundleContext) throws Exception {
PriceAService service = new PriceAServiceImpl();
bundleContext.registerService(PriceAService.class.getName(), service, null);
System.out.println("Stock price provider A is registered");
Activator.context = bundleContext;
}

public void stop(BundleContext bundleContext) throws Exception {
System.out.println("Stopping provider A");
Activator.context = null;
}
}

PriceAService.java
package com.axmor.osgiexample.providera;

public interface PriceAService {
public int getPrice();
}

PriceAServiceImpl.java
package com.axmor.osgiexample.providera;

public class PriceAServiceImpl implements PriceAService {

private static final int REFRESH_RATE = 3 * 1000;
private int price;
private long time = 0;

public int getPrice() {
long currentTime = System.currentTimeMillis();
if (currentTime - time > REFRESH_RATE) {
price = (int) (Math.random() * 100);
time = currentTime;
}
return price;
}
}

"com.axmor.osgiexample.providerb" has the almost the same code.

Open MANIFEST.MF and add the package with the code to Exported Packages for both bundles (see Figure 1).

Create a new plugin project "com.axmor.osgiexample.stockanalyser" which will use services from the described bundles and provide simple information based on received prices. Add previously created bundles to Required Plug-ins in MANIFEST.MF (see Figure 2). Add "com.axmor.osgiexample.stockanalyser" package to Exported Packages.

Activator.java

package com.axmor.osgiexample.stockanalyser;


import org.osgi.framework.BundleActivator;

import org.osgi.framework.BundleContext;

import org.osgi.framework.ServiceReference;


import com.axmor.osgiexample.providera.PriceAService;

import com.axmor.osgiexample.providerb.PriceBService;


public class Activator implements BundleActivator {


private BundleContext context;


public void start(BundleContext bundleContext) throws Exception {

this.context = bundleContext;


ServiceReference reference1 = context.getServiceReference(PriceAService.class.getName());

PriceAService serviceA = (PriceAService) context.getService(reference1);

ServiceReference reference2 = context.getServiceReference(PriceBService.class.getName());

PriceBService serviceB = (PriceBService) context.getService(reference2);


StockAnalyserService analyserService = new StockAnalyserServiceImpl();

analyserService.setServiceA(serviceA);

analyserService.setServiceB(serviceB);

context.registerService(StockAnalyserService.class.getName(), analyserService, null);

System.out.println("Stock Analyser service is registered");

}


public void stop(BundleContext bundleContext) throws Exception {

System.out.println("Stoping Stock Analyser");

this.context = null;

}

}

StockAnalyserServiceImpl.java

package com.axmor.osgiexample.stockanalyser;


import com.axmor.osgiexample.providera.PriceAService;

import com.axmor.osgiexample.providerb.PriceBService;


public class StockAnalyserServiceImpl implements StockAnalyserService {


private PriceAService serviceA;

private PriceBService serviceB;


public double getAverageValue() {

int priceA = serviceA.getPrice();

int priceB = serviceB.getPrice();

return (double) (priceA + priceB) / 2;

}


public int getMinPrice() {

int priceA = serviceA.getPrice();

int priceB = serviceB.getPrice();

return priceA <= priceB ? priceA : priceB;

}


public int getMaxPrice() {

int priceA = serviceA.getPrice();

int priceB = serviceB.getPrice();

return priceA >= priceB ? priceA : priceB;

}


public synchronized void setServiceA(PriceAService service) {

this.serviceA = service;


}


public synchronized void setServiceB(PriceBService service) {

this.serviceB = service;

}

}

 

Enable the "Activate this plug-in when one of its classes is loaded" option in MANIFEST.MF for all created bundles (see Figure 3). Testable application is ready.

Bundle with Tests
Now we are able to create tests for the described application.

Create an OSGi bundle as before. An activator class is not required; therefore, you can remove it or disable the appropriate option in Eclipse wizard.

Add following bundles to Required Plug-ins sections in MANIFEST.MF:

  • com.axmor.osgiexample.providera
  • com.axmor.osgiexample.providerb
  • com.axmor.osgiexample.stockanalyser
  • org.junit

Create test classes:

TestProviderA.java

package com.axmor.osgiexample.tests;


import static org.junit.Assert.assertEquals;

import static org.junit.Assert.assertNotSame;

import static org.junit.Assert.assertTrue;


import org.junit.Before;

import org.junit.Test;

import org.osgi.framework.BundleContext;

import org.osgi.framework.FrameworkUtil;

import org.osgi.framework.ServiceReference;


import com.axmor.osgiexample.providera.PriceAService;


public class TestProviderA {


private BundleContext bundleContext = null;

private PriceAService serviceA = null;


@Before

public void init() {

bundleContext = FrameworkUtil.getBundle(getClass()).getBundleContext();

ServiceReference ref = bundleContext.getServiceReference(PriceAService.class.getName());

serviceA = (PriceAService) bundleContext.getService(ref);

}


@Test

public void testPriceLimit() {

System.out.println("***************");

int priceA = serviceA.getPrice();

assertTrue("Price must be more than 0", priceA >= 0);

assertTrue("Price must be less than 100", priceA <= 100);

System.out.println("Price for company A: $" + priceA + " OK");

}


@Test

public void testPriceChanging() throws Exception {

System.out.println("***************");

for (int i = 0; i < 3; i++) {

int price1 = serviceA.getPrice();

Thread.sleep(3500);

int price2 = serviceA.getPrice();

int price3 = serviceA.getPrice();

// implementation of the Price A provider allowed price to be

// unchanged,

// but let the test define such situation as incorrect

assertNotSame("Price must change", price1, price2);

assertEquals("Price should be the same", price2, price3);

System.out.println("Price for company A was changed from $" + price1 + " to $"

+ price2 + " OK");

}

}

}

TestProviderB.java is almost the same as TestProviderA.java

TestAnalyser.java

package com.axmor.osgiexample.tests;


import static org.junit.Assert.assertEquals;


import org.junit.Before;

import org.junit.Test;

import org.osgi.framework.BundleContext;

import org.osgi.framework.FrameworkUtil;

import org.osgi.framework.ServiceReference;


import com.axmor.osgiexample.providera.PriceAService;

import com.axmor.osgiexample.providerb.PriceBService;

import com.axmor.osgiexample.stockanalyser.StockAnalyserService;



public class TestAnalyser {


private BundleContext bundleContext = null;

private StockAnalyserService analyzerService = null;

private PriceAService serviceA = null;

private PriceBService serviceB = null;


@Before

public void init() {

bundleContext = FrameworkUtil.getBundle(getClass()).getBundleContext();

ServiceReference ref = bundleContext.getServiceReference(StockAnalyserService.class

.getName());

analyzerService = (StockAnalyserService) bundleContext.getService(ref);

ref = bundleContext.getServiceReference(PriceAService.class.getName());

serviceA = (PriceAService) bundleContext.getService(ref);

ref = bundleContext.getServiceReference(PriceBService.class.getName());

serviceB = (PriceBService) bundleContext.getService(ref);

}


@Test

public void testCheckAverageValue() throws Exception {

System.out.println("***************");

for (int i = 0; i < 3; i++) {

Thread.sleep(3500);

int priceA = serviceA.getPrice();

int priceB = serviceB.getPrice();

double avg = analyzerService.getAverageValue();

double expectedAvgVal = (double) (priceA + priceB) / 2;

assertEquals(expectedAvgVal, avg, 0);

System.out.println("Price A = " + priceA + " Price B = " + priceB);

System.out.println("Stock average value: " + avg + " OK");

}

}


@Test

public void testCheckMinPrice() throws Exception {

System.out.println("***************");

for (int i = 0; i < 3; i++) {

Thread.sleep(3500);

int priceA = serviceA.getPrice();

int priceB = serviceB.getPrice();

int min = analyzerService.getMinPrice();

int expectedMin = Math.min(priceA, priceB);

assertEquals(expectedMin, min);

System.out.println("Price A = " + priceA + " Price B = " + priceB);

System.out.println("Stock min price: " + min + " OK");

}

}


@Test

public void testCheckMaxPrice() throws Exception {

System.out.println("***************");

for (int i = 0; i < 3; i++) {

Thread.sleep(3500);

int priceA = serviceA.getPrice();

int priceB = serviceB.getPrice();

int max = analyzerService.getMaxPrice();

int expectedMax = Math.max(priceA, priceB);

assertEquals(expectedMax, max);

System.out.println("Price A = " + priceA + " Price B = " + priceB);

System.out.println("Stock max price: " + max + " OK");

}

}

}

Now you can run each test in Eclipse as a JUnit Plug-in test (see Figure 4). You are able to change the run configuration: include or exclude bundles from the workspace and target platform (see Figure 5). By default, the run configuration will use the "Launch with all workspace and enabled target plug-ins" option. To start above tests, you need not change the run configuration option.

Building and Testing with Tycho
In this section we will add a configuration to build and test the created application using Maven.

Create parent Maven POM and POMs for each project:

Parent pom.xml


<?xml version="1.0" encoding="UTF-8"?>

<project>

<modelVersion>4.0.0</modelVersion>

<groupId>com.axmor.osgiexample</groupId>

<artifactId>parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

<packaging>pom</packaging>

<modules>

<module>com.axmor.osgiexample.providera</module>

<module>com.axmor.osgiexample.providerb</module>

<module>com.axmor.osgiexample.stockanalyser</module>

<module>com.axmor.osgiexample.tests</module>

</modules>


<properties>

<tycho-version>0.10.0</tycho-version>

</properties>


<repositories>

<repository>

<id>helios</id>

<layout>p2</layout>

<url>http://download.eclipse.org/releases/helios</url>

</repository>

</repositories>


<build>

<plugins>

<plugin>

<groupId>org.sonatype.tycho</groupId>

<artifactId>tycho-maven-plugin</artifactId>

<version>${tycho-version}</version>

<extensions>true</extensions>

</plugin>

<plugin>

<groupId>org.sonatype.tycho</groupId>

<artifactId>target-platform-configuration</artifactId>

<version>${tycho-version}</version>

<configuration>

<resolver>p2</resolver>

</configuration>

</plugin>

</plugins>

</build>


</project>

Pay attention that the p2 repository was used as a target platform for the Tycho plugin. You can change it to another or your own target platform.

All child POMs will inherit the Tycho plugin configuration from the parent POM.

Testable project's pom.xml

<?xml version="1.0" encoding="UTF-8"?>

<project>

<modelVersion>4.0.0</modelVersion>


<parent>

<groupId>com.axmor.osgiexample</groupId>

<artifactId>parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

</parent>


<artifactId>com.axmor.osgiexample.stockanalyser</artifactId>

<packaging>eclipse-plugin</packaging>


</project>


pom.xml for project with tests


<?xml version="1.0" encoding="UTF-8"?>

<project>

<modelVersion>4.0.0</modelVersion>


<parent>

<groupId>com.axmor.osgiexample</groupId>

<artifactId>parent</artifactId>

<version>1.0.0-SNAPSHOT</version>

</parent>


<artifactId>com.axmor.osgiexample.tests</artifactId>

<packaging>eclipse-test-plugin</packaging>


<build>

<plugins>

<plugin>

<groupId>org.sonatype.tycho</groupId>

<artifactId>maven-osgi-test-plugin</artifactId>

</plugin>

</plugins>

</build>


</project>


Start build/test process from root directory:

mvn install

See Figure 6 for results.

Conclusion
Test development for OSGi applications is rather complex, but an inherent part of the development process. Programmers will meet many problems and obstacles before carving out a complete testing solution. We hope our experiences and tips shared in this article will help programmers avoid typical mistakes.

Resources

  1. http://java.dzone.com/articles/dozen-osgi-myths-and
  2. http://java.dzone.com/articles/putting-osgi-test-pax-exam
  3. http://tycho.sonatype.org/how-to-create-a-new-osgi-bundle.html
  4. http://www.vogella.de/articles/OSGi/article.html

More Stories By Marat Meirmanov

Marat Meirmanov is a Senior Software Engineer at Axmor Software, a software development company located in Novosibirsk, Russia. He has over 5 years of experience in software development and holds a bachelor degree in Computer Science. He has been a developer in several successfully completed projects for US customers. During the last year of working in Axmor’s IBM Solutions Group, he has acted as a QA Development Lead in a large-scale enterprise project.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.