In the introductory chapter on OSGi (Chapter 1), you might recall it was classes that needed to include the registration and lookup sequences for OSGi services using the framework's API.

Under such circumstances, testing can get complicated. With a class's code intertwined with OSGi calls, it can be difficult to create the necessary tests to guarantee the integrity of a class's OSGi and business logic. In addition, it requires thinking about tests in broader terms, such as how OSGi services need to interact with business logic, which militates against one of the basic principles of testing: simplicity.

Since Spring-DM relies on the use of descriptors to register and look up OSGi services on behalf of classes, a class's code normally doesn't contain this type of logic. This separation allows a class's business logic to be tested using very simple cases, as done in Chapter 2, while OSGi logic is also tested using separate and simple cases.

This approach is one of the cornerstones to using the Spring Framework—allowing classes to remain POJOs and define a class's dependencies elsewhere, thus facilitating the creation of tests.

Still, this type of testing done at the class level—unit testing—can become very different when OSGi comes into the picture. In a typical unit test (the business logic kind) consisting of proving the integrity of getter-setter methods, a workflow, or a mathematical operation, a testing framework has a one-on-one interaction with the class it is testing.

By "one-on-one interaction," I mean that a test sequence consists of applying an input to a class's method, holding its state, and verifying whether the return value is the desired output. It is a back-and-forth process between class and testing framework. But what happens when a class needs to get ahold of an outside resource to perform a test?

This type of testing—integration testing—is unavoidable when testing OSGi and Spring-DM applications. Since even OSGi services used in single classes need to be registered and/or looked up in an OSGi environment, this requires the presence of an OSGi environment to fulfill tests—just as an RDBMS is an outside resource required to perform integration tests, as illustrated in Chapter 2.

This implies that there is little scope for unit testing in OSGi, since all testing involving OSGi and Spring-DM is considered integration testing, due to this reliance on an outside resource (OSGi framework).

Still you may be wondering, what does testing an application using OSGi and Spring-DM really accomplish? The purpose behind integration testing in an environment like OSGi is to verify the correctness of behavior such as the following:

All these questions revolve around OSGi and are best answered in a testing environment, where their potential for disruption is limited. In addition, OSGi testing also ensures that once an OSGi and Spring-DM code base start to evolve, a minimum benchmark or "safety net" is kept so as to not break older and relied-upon OSGi logic. In essence, the same benefits as non-OSGi testing apply to OSGi and Spring-DM testing.

After this brief overview of testing with OSGi and Spring-DM, let's revisit the same unit and integration techniques presented in Chapter 2, only this time applied to the OSGi application created in Chapter 7.

The title to this section might sound strange, but there are non-OSGi tests that can be performed on OSGi applications. How so? This type of testing refers to unit testing an OSGi application's non-OSGi logic, as well as performing the corresponding integration tests to ensure an application works correctly with something like an RDBMS.

Chapter 7 's application, even though designed around OSGi (being composed of five bundles and operating on the basis of multiple OSGi services), still contains logic that can and should be tested outside the context of OSGi. Since Chapter 7 's application is an OSGi version ported from Chapter 2 's stand-alone Spring application, you've already created some of these tests.

Listing 2-11 in Chapter 2 illustrates a unit test that can be applied equally to a code base designed around OSGi principles. This unit test ensures the classes belonging to the application's model bundle have the correct behavior in terms of their getter-setter methods, which of course has nothing to do with OSGi.

Another aspect of testing that requires attention and is outside the scope of OSGi is related to the business logic executed against an RDBMS. Listing 2-12 in Chapter 2 illustrates the integration test applicable to the application's DAO class. This integration test ensures the class belonging to the service DAO bundle has the correct behavior when it interacts with an RDBMS.

In the case of the integration test in Listing 2-12, it should be noted that it is designed to test a DAO class using the JPA, unlike Chapter 7 's application, which introduced a JDBC-backed DAO class. As already outlined in Chapter 7, OSGi's modularity allows you to easily swap bundles using either RDBMS access strategy (JPA or JDBC).

However, for the sake of completeness and to illustrate how an RDBMS integration test can be performed against a DAO class based on JDBC, Listing 9-1 shows this test.

package com.apress.springosgi.ch9.tests;

import java.util.Date;
import java.util.List;

import com.apress.springosgi.ch9.model.HelloWorld;
import com.apress.springosgi.ch9.model.Person;
import com.apress.springosgi.ch9.service.HelloWorldService;

import org.springframework.test.AbstractTransactionalDataSourceSpringContextTests;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;
import org.junit.Test;

import org.springframework.dao.EmptyResultDataAccessException;
import org.springframework.orm.ObjectRetrievalFailureException;

public class HelloWorldServiceIntegrationTests extends

 AbstractTransactionalDataSourceSpringContextTests {

protected HelloWorldService helloWorldService;

    public void setHelloWorldService(HelloWorldService helloWorldService) {
        this.helloWorldService = helloWorldService;
    }

    private static long EnglishId;
    private static long SpanishId;
    private static long FrenchId;
    private static boolean databasePopulated = false;

    protected void populateDatabase() {
       ("classpath:/com/apress/springosgi/ch9/tests/helloworld-hsqldb.sql", false);
        databasePopulated = true;
    }

    protected String[] getConfigLocations() {
        return new String[] { "classpath:/com/apress/springosgi/ch9/tests/

helloworld-service.xml" };
    }

    protected void onSetUpBeforeTransaction() throws Exception {
        // This method is executed before each test method
        // Database tables and data only inserted once
        if (!databasePopulated) {
            populateDatabase();
            HelloWorld hw1 = new HelloWorld("English",
                                            "Hello World!", new Date(),
                                            new Person("John","Smith",45.00));
            HelloWorld hw2 = new HelloWorld("Spanish",
                                            "Hola Mundo!", new Date(),
                                            new Person("Carlos","Perez",40.00));
            HelloWorld hw3 = new HelloWorld("French",
                                            "Bonjour Monde!", new Date(),
                                            new Person("Pierre","LeClair",40.00));
            helloWorldService.save(hw1);
            helloWorldService.save(hw2);
            helloWorldService.save(hw3);

            EnglishId = helloWorldService.findByLanguage("English").get(0).getId();
            SpanishId = helloWorldService.findByLanguage("Spanish").get(0).getId();
            FrenchId = helloWorldService.findByLanguage("French").get(0).getId();
        }

    }

public void testFindById() {
        HelloWorld hw = helloWorldService.findById(EnglishId);
        assertNotNull(hw);
        assertEquals("English", hw.getLanguage());
    }

    try {
            HelloWorld hw = helloWorldService.findById(10000);
        } catch(EmptyResultDataAccessException expected) {
            assertTrue(true);
        }
    }

    public void testFindByLanguage() {
        List<HelloWorld> hws = helloWorldService.findByLanguage("Spanish");
        assertEquals(1, hws.size());
        HelloWorld hw = hws.get(0);
        assertEquals("Hola Mundo!", hw.getMessage());
    }

    public void testFindByBadLanguage() {
        List<HelloWorld> hws = helloWorldService.findByLanguage("Catalan");
        assertEquals(0, hws.size());
    }

    public void testFindByTranslatorFirstName() {
        List<HelloWorld> hws = helloWorldService.findByTranslatorFirstName("John");
        assertEquals(1, hws.size());
        HelloWorld hw = hws.get(0);
        assertEquals(EnglishId, hw.getId());
    }

    public void testFindByTranslatorLastName() {
        List<HelloWorld> hws = helloWorldService.findByTranslatorLastName

("LeClair");
        assertEquals(1, hws.size());
        HelloWorld hw = hws.get(0);
        assertEquals(FrenchId, hw.getId());
    }

 public void testFindByTranslatorFirstNameDoesNotExist() {
        try{
            List<HelloWorld> hws = helloWorldService.findByTranslatorFirstName

("Bill");
        } catch(EmptyResultDataAccessException expected) {
            assertTrue(true);
        }
    }

public void testFindByTranslatorLastNameDoesNotExist() {
        try {
            List<HelloWorld> hws = helloWorldService.findByTranslatorLastName

("Matsusaka");
        } catch(EmptyResultDataAccessException expected) {
            assertTrue(true);
        }
    }

    public void testFindByTranslatorHourlyRateOver() {
        List<HelloWorld> hws = helloWorldService.findByTranslatorHourlyRateOver

(42.00);
        assertEquals(1, hws.size());
    }

    public void testModifyHelloWorldMessage() {
        String oldHelloMessage = "Bonjour Monde!";
        String newHelloMessage = "Bonjour Le Monde!";
        HelloWorld hw = helloWorldService.findByLanguage("French").get(0);
        hw.setMessage(newHelloMessage);
        HelloWorld hw2 = helloWorldService.update(hw);
        assertEquals(newHelloMessage, hw2.getMessage());
        List<HelloWorld> hw3 = helloWorldService.findByMessage(oldHelloMessage);
        assertEquals(0, hw3.size());
        hw3 = helloWorldService.findByMessage(newHelloMessage);
        assertEquals(1, hw3.size());
        HelloWorld newhw3 = hw3.get(0);
        assertEquals(newHelloMessage, newhw3.getMessage());
    }

     public void testDeleteHelloWorldCascade() {
        String transFirstName = "Carlos";
        HelloWorld hw = helloWorldService.findByTranslatorFirstName

(transFirstName).get(0);
        int transCountBefore = countRowsInTable("person");
        int helloCountBefore = countRowsInTable("helloworld");
        helloWorldService.delete(hw);
        try {
            List<HelloWorld>    hws = helloWorldService.findByTranslatorFirstName

(transFirstName);
        } catch(EmptyResultDataAccessException expected) {
            assertTrue(true);
        }

        int transCountAfter = countRowsInTable("person");
        int helloCountAfter = countRowsInTable("helloworld");
        assertEquals(transCountBefore −1, transCountAfter);

assertEquals(helloCountBefore −1, helloCountAfter);
    }

    public void testFindAll() {
        List<HelloWorld> hws = helloWorldService.findAll();
        assertEquals(3, hws.size());
    }

}

The first thing you should note about this listing is that it defines the same test methods as its JPA counterpart in Listing 2-12. However, the logic used to perform each test is different in that the test is being performed against a DAO class based on JDBC.

Notice how this test class extends AbstractTransactionalDataSourceSpringContextTests. This class provided by the Spring Framework facilitates the testing of JDBC-backed classes, just as the AbstractJpaTests class provided by the Spring Framework is used to facilitate testing of JPA-backed classes.

Though the mechanisms provided by these last two Spring helper classes is fairly similar, there are some differences you need to be aware of. First is the getConfigLocations method, which contains the configuration parameters to set up a test RDBMS; this RDBMS will in turn be used to inject a helloWorldService reference into the test class. Listing 9-2 illustrates the helloworld-service.xml file declared in getConfigLocations.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/

spring-beans.xsd">

   <bean id="helloWorldService"
         class="com.apress.springosgi.ch9.servicedaojdbc.HelloWorldDAO">
     <property name="dataSource" ref="dataSource"/>
   </bean>

   <bean id="dataSource" class="org.springframework.jdbc.datasource.

DriverManagerDataSource">
      <property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
      <property name="url" value="jdbc:hsqldb:mem:springosgi"/>
      <property name="username" value="sa" />
      <property name="password" value="" />
   </bean>

<bean id="transactionManager" class="org.springframework.jdbc.datasource.

DataSourceTransactionManager">
      <property name="dataSource" ref="dataSource"/>
   </bean>

</beans>

Serving as basis for comparison, take a look at Listing 2-13 in Chapter 2, which illustrates the helloworld-service.xml file used for JPA testing. The only thing that is identical between these two modes of testing (JPA and JDBC) is the dataSource declaration, which corresponds to an in-memory HSQLDB RDBMS.

The transactionManager declaration in this case is only applied to the dataSource element. In Listing 2-13, note the transactionManager declaration, in addition to the dataSource element, is applied to the entityManagerFactory element, which is JPA specific.

Next you can observe the helloWorldService declaration, which is injected with the dataSource bean. This is in contrast with the JPA version, which is injected with an entityManagerFactory bean. This difference is due to how JPA- and JDBC-backing classes operate. A JPA class taps an RDBMS through an entityManagerFactory instance, whereas a JDBC class gets ahold of an RDBMS through a raw data source.

In addition, the presence of an entityManagerFactory—or lack thereof—influences how a test RDBMS is set up. If you look closely at the JPA version in Listing 2-13, you will note the <property name="generateDdl" value="true"/> statement inside the entityManagerFactory element.

This statement allows the JPA entity manager to execute Data Definition Language (DDL) against an RDBMS. As consequence, this permits a test to be started without any preexisting tables in an RDBMS. (Note that DDL corresponds to CREATE TABLE type statements to create data structures in an RDBMS.)

Since this is JPA-specific behavior, a JDBC test needs to take this into account, creating the necessary RDBMS tables (DDL) at the outset of a test, which is the purpose of the populateDatabase method in the JDBC test class (Listing 9-1).

This last method relies on the executeSqlScript method, which forms part of the Spring AbstractTransactionalDataSourceSpringContextTests class and is used to execute an SQL DDL script against the data source configured for the test class. Listing 9-3 illustrates this script.

CREATE TABLE Person(ID IDENTITY, FNAME VARCHAR(200),LNAME VARCHAR(200),

hourlyRate DOUBLE);

CREATE TABLE HelloWorld(ID IDENTITY, language VARCHAR(200),

message VARCHAR(200), transdate DATE, translator_id INTEGER NOT NULL, 

CONSTRAINT FK1 FOREIGN KEY (translator_id) REFERENCES Person(ID))

This listing contains the two DDL statements that will be executed against the in-memory HSQLDB RDBMS. It's important to note that this script is only executed once—the same number of times the populateDatabase method is called, which is controlled by the databasePopulated field. This is due to the sequence of steps in the testing process.

When the testing process starts, Spring will instantiate an in-memory HSQLDB that will last for the entire sequence of test methods (testFindBy*, testModify, testDelete, etc.). Prior to executing each of these test methods, which rely on the presence of data in the RDBMS, the onSetUpBeforeTransaction method will be invoked on each occasion.

This behavior of the onSetUpBeforeTransaction method allows each test method to start with a clean set of data in the RDBMS (if so required), but at the same time and given its recursive nature, also executes the SQL DDL script against the RDBMS on each occasion. This process leads to errors because tables (DDL) can only be created once against the same RDBMS instance. Hence the need for a protective clause based on the databasePopulated field in order to invoke the populateDatabase method—and with it the executeSqlScript method—only once.

The test, including its class, context file, and DDL script, can be started with JUnit using a tool like Apache Ant, just as you did for the JPA DAO version in Chapter 2. The book's accompanying download includes this test in a staged form ready to be executed with Apache Ant.

This concludes the discussion on non-OSGi testing performed on OSGi applications, as well as analysis of the parts needed to test a DAO JDBC class using Spring artifacts and an in-memory RDBMS. Next, I will shift focus to OSGi testing and how Spring-DM supports this process.

As mentioned at the outset of this chapter, the process of performing OSGi tests requires the presence of an OSGi environment in order to guarantee that the behavior of bundles is appropriate once in a production environment. This creates the first requirement for OSGi testing: a means to bootstrap an OSGi environment in which to run tests.

Since the tests themselves need to interact with an OSGi environment's registry and services, this creates a second requirement: a need to package test classes in an OSGi bundle. This may seem awkward, especially compared to non-OSGi unit and integration test classes that can be executed directly from the file system, but in OSGi classes need to be prepped and installed in OSGi's de facto deployment format—the bundle. They simply can't be run in isolation even if they are test classes.

In addition, a third requirement may arise in the form of provisioning the OSGi testing environment with additional bundle dependencies needed to run a test. For example, in order to perform a test on an OSGi web bundle, you would have to install an OSGi'fied web container like Tomcat or Jetty into the OSGi testing environment prior to running the test itself, since the target web bundle requires such a dependency to operate.

These requirements alone are a lot of work to be fulfilling on each test case involving OSGi, which is the reason behind Spring-DM's testing framework. The purpose of Spring-DM's testing framework is to streamline the following process:

By doing so, the Spring-DM testing framework lets you concentrate on the primary task of creating tests. In order to use the Spring-DM testing framework, you will need to rely on a series of classes included in Spring-DM and on which all tests should be designed. Just as you've used other Spring classes—such as AbstractTransactionalDataSourceSpring ContextTests and AbstractJpaTests—which aid in the creation of tests by allowing the placement of test methods in a class without your needing to worry about the setup process, so too are these Spring-DM test classes aimed at reducing the amount of "legwork" needed to create tests.

I will illustrate the use of these test classes shortly, but for the moment I want to continue with a few more important details you'll need to know on Spring-DM's testing framework.

Spring-DM's testing framework allows testing to be performed against any of the three major OSGi frameworks: Eclipse Equinox, Apache Felix, and Knopflerfish. This guarantees that any bundle's OSGi logic is compatible with any of these three implementations.

It's also important that you realize Spring-DM's testing framework is tightly pegged against Apache Maven, relying on this last dependency management tool for the invocation of tests and management of bundle dependencies that may be needed by the tests themselves.

Since I opted to stay away from Apache Maven due to its more demanding setup in favor of Apache Ivy in Chapter 7, all the tests presented in this chapter will be designed to operate with Apache Ivy as the dependency management tool and Apache Ant as the build tool.

Having covered this background on Spring-DM's testing framework, you may be wondering what the general process for creating tests in Spring-DM is. The following list presents this three-step sequence:

Knowing this three-step sequence, let's create one of the most basic Spring-DM tests possible with the help of Apache Ivy and Apache Ant.

AbstractOptionalDependency-
InjectionTests

AbstractOnTheFlyBundleCreator
Tests

AbstractConfigurableBundle
CreatorTests

AbstractConfigurableBundle
CreatorTests

package com.apress.springosgi.ch9.testsosgi;

import org.springframework.osgi.test.AbstractConfigurableBundleCreatorTests;
import org.springframework.osgi.test.provisioning.ArtifactLocator;

import org.osgi.framework.Constants;

import com.apress.springosgi.ch9.testsosgi.testivyprovisions.

LocalFileSystemIvyRepository;

public class BootstrapTest extends AbstractConfigurableBundleCreatorTests {

    public String getRootPath() {
        return"file:./classes/";
    }

public ArtifactLocator getLocator() {
        return new LocalFileSystemIvyRepository();
    }

    public void testOsgiPlatformStarts() throws Exception {
        System.out.println("OSGi Framework Vendor : " + bundleContext.

getProperty(Constants.FRAMEWORK_VENDOR));
        System.out.println("OSGi Framework Vendor Version : " + bundleContext.

getProperty(Constants.FRAMEWORK_VERSION));
        System.out.println("OS Name and Version :  " + bundleContext.

getProperty(Constants.FRAMEWORK_OS_NAME) + "-" + bundleContext.

getProperty(Constants.FRAMEWORK_OS_VERSION));
    }
}

com.springsource.org.aopalliance.1.0.0,
com.springsource.junit,3.8.2,
com.springsource.org.objectweb.asm.2.2.3,
com.springsource.slf4j.api,1.5.0,
com.springsource.slf4j.log4j.1.5.0,
com.springsource.slf4j.org.apache.commons.logging,1.5.0,
org.springframework.spring-aop.2.5.5,
org.springframework.spring-beans,2.5.5,
org.springframework.spring-context,2.5.5,
org.springframework.spring-core.2.5.5,
org.springframework.spring-test.2.5.5,
org.springframework.osgi.log4j.osgi.1.2.15-SNAPSHOT,
org.springframework.osgi.spring-osgi-annotation.1.2.0-m1,
org.springframework.osgi.spring-osgi-core.1.2.0-m1,
org.springframework.osgi.spring-osgi-extender.1.2.0-m1,
org.springframework.osgi.spring-osgi-io.1.2.0-m1,
org.springframework.osgi.spring-osgi-test.1.2.0-m1

<ivy-module version="2.0">
    <info organisation="apache" module="hello-ivy"/>
    <configurations>
         <conf name="build"/>
    </configurations>
   <!-- Download bundle dependencies for application testing (Non-OSGi and OSGi)-->
       <dependency org="org.junit" name="com.springsource.org.junit" rev="4.5.0"/>
       <dependency org="org.hsqldb" name="com.springsource.org.hsqldb" 

rev="1.8.0.9" />
       <dependency org="org.objectweb.asm"

name="com.springsource.org.objectweb.asm" rev="2.2.3"/>
       <dependency org="org.aopalliance" name="com.springsource.org.aopalliance" 

rev="1.0.0"/>
        <dependency org="org.slf4j" name="com.springsource.slf4j.log4j" 

rev="1.5.0"/>
       <dependency org="org.springframework" name="spring-aop" rev="2.5.5.A"/>
       <dependency org="org.springframework" name="spring-beans" rev="2.5.5.A"/>
       <dependency org="org.springframework" name="spring-context" rev="2.5.5.A"/>
       <dependency org="org.springframework" name="spring-core" rev="2.5.5.A"/>
       <dependency org="org.springframework" name="spring-test" rev="2.5.5.A"/>
       <dependency org="org.springframework.osgi" name="log4j.osgi" 

rev="1.2.15-SNAPSHOT">

<artifact name="log4j.osgi" type="jar" 

url="http://s3.amazonaws.com/maven.springframework.org/osgi/org/springframework/

osgi/log4j.osgi/1.2.15-SNAPSHOT/log4j.osgi-1.2.15-20080314.153110-17.jar"/>
       </dependency>
       <dependency org="org.springframework.osgi" name="spring-osgi-annotation"

rev="1.2.0-m1"/>
       <dependency org="org.springframework.osgi" name="spring-osgi-test"

rev="1.2.0-m1"/>
       <dependency org="org.eclipse.osgi" name="org.eclipse.osgi"

rev="3.5.0.200811061137"/>
       <dependency org="org.apache.felix" name="org.apache.felix.main" rev="1.0.4"/>
       <dependency org="knopflerfish" name="framework" rev="2.1.0"/>
 </dependencies>
</ivy-module>

<ivysettings>

  <settings defaultResolver="chain-springosgi"/>

     <caches defaultCacheDir="${basedir}/ivylib">
     </caches>

  <resolvers>
    <chain name="chain-springosgi">
        <filesystem name="my-repository">
          <ivy pattern="${basedir}/ivylib/[organisation]/[module]/[revision]/

[artifact]-[revision].[ext]"/>
          <artifact pattern="${basedir}/ivylib/[organisation]/[module]/[revision]/

[artifact]-[revision].[ext]"/>
        </filesystem>

       <url name="spring-release-repo">
                <ivy pattern="http://repository.springsource.com/ivy/bundles/

release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
                <artifact pattern="http://repository.springsource.com/ivy/bundles/

release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
       </url>

<url name="spring-external-repo">
                <ivy pattern="http://repository.springsource.com/ivy/bundles/

external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
                <artifact pattern="http://repository.springsource.com/ivy/bundles/

external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" />
       </url>

       <url name="spring-milestone-repo" m2compatible="true">
                <artifact pattern="http://s3.amazonaws.com/

maven.springframework.org/milestone/[organisation]/[module]/

[revision]/[artifact]-[revision].[ext]"/>
       </url>

       <ibiblio name="ibiblio"/>

       <url name="default-repo" m2compatible="true">
                <artifact pattern="http://repo1.maven.org/maven2/[organisation]/

[module]/[revision]/[artifact]-[revision].[ext]"/>
       </url>


       <url name="knoper-repo" m2compatible="true">

                   <artifact pattern="http://springframework.svn.sourceforge.net/

svnroot/springframework/repos/repo-ext/[organisation]/[module]/[revision]/

[artifact]-[revision].[ext]"/>
       </url>
    </chain>

  </resolvers>


</ivysettings>

1     <?xml version="1.0"?>
2    <project xmlns:ivy="antlib:org.apache.ivy.ant" default="init" basedir=".">

3     <target name="init" description="Apress - Pro Spring-OSGi">
4       <tstamp/>
5       <property name="projectname" value="Pro Spring-OSGi"/>

6       <echo message="-------${projectname}------"/>
7       <property name="debug"          value="on"/>
8       <property name="optimize"          value="off"/>
9       <property name="deprication"      value="off"/>
10      <property name="build.compiler" value="modern"/>
11      <property name="target.vm"         value="1.5"/>
12      <property name="build.dir"         value="classes"/>
13      <property name="dist.dir"         value="dist"/>
14      <property name="src.dir"         value="src"/>
15      <property name="lib.dir"         value="lib/build"/>

16      <!-- Load JARs onto the classpath, taken from lib/build sub-dir -->

17      <path id="classpath">
18       <fileset dir="${lib.dir}">
19        <include name="*.jar"/>
20       </fileset>
21       <pathelement location="${build.dir}"/>
22      </path>
23    </target>

24    <target name="compile" depends="init" description="Compile code">

25      <ivy:retrieve pattern="lib/[conf]/[artifact]-[revision].[ext]" />

26      <echo message="-------Compiling code for Pro-Spring OSGi------"/>

27      <mkdir dir="${build.dir}"/>
28      <mkdir dir="${dist.dir}"/>

29      <javac srcdir="${src.dir}"
30             destdir="${build.dir}"
31             debug="${debug}"
32             optimize="${optimize}"
33             deprecation="${deprecation}"
34             target="${target.vm}">
35         <classpath refid="classpath"/>
36      </javac>

37     <copy todir="${build.dir}">
38               <fileset dir="${src.dir}">
39    <!-- Some of the following statements are relevant to Ch2 -->
40    <!-- They are present here because the same compile task is used -->
41                   <include name="**/*.properties"/>
42                   <include name="**/*.xml"/>
43                   <include name="**/*.sql"/>
44                   <include name="**/*.MF"/>
45                   <exclude name="**/*.java"/>
46                   <exclude name="META-INF/**"/>
47                   <exclude name="WEB-INF/**"/>
48                   <exclude name="GUI/**"/>
49                </fileset>
50      </copy>
51    </target>

52    <target name="ch9" depends="compile" description="Build Chapter 9

Spring-OSGi Application">

53      <echo message="-------------- Building Chapter 9 Spring-OSGi Application

for Pro Spring-OSGi --------------"/>
54         <property name="ch9.dir"          value="${dist.dir}/ch9/"/>
55         <mkdir dir="${ch9.dir}"/>
56         <property name="test.dir"         value="${ch9.dir}/tests"/>
57         <mkdir dir="${test.dir}"/>
58        <echo message="-------------- Starting Unit and Integration Testing

(OSGi) --------------"/>
59          <junit printsummary="yes" fork="yes">
60          <sysproperty key="localRepository" value="ivylib"/>
61          <sysproperty key="org.springframework.osgi.test.framework"

value="org.springframework.osgi.test.platform.KnopflerfishPlatform"/>

62    <!--           <sysproperty key="org.springframework.osgi.test.framework"

value="org.springframework.osgi.test.platform.FelixPlatform"/> -->
63  <!--          <sysproperty key="org.springframework.osgi.test.framework"

value="org.springframework.osgi.test.platform.EquinoxPlatform"/>    -->
64         <classpath refid="classpath"/>
65         <formatter type="brief"/>
66         <batchtest todir="${test.dir}">
67            <fileset dir="${build.dir}">
68              <include name="com/apress/springosgi/ch9/testsosgi/*"/>
69            </fileset>
70         </batchtest>
71        </junit>
72        <echo message="-------------- Ending Unit and Integration Testing

(OSGi) --------------"/>
73    </target>
74    </project>

Testsuite: com.apress.springosgi.ch9.testsosgi.BootstrapTest
Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.197 sec

------------- Standard Output ---------------

18:25:48.708 [main] DEBUG c.a.s.ch9.testsosgi.BootstrapTest - About to start

Equinox OSGi Platform

18:25:49.614 [main] INFO  c.a.s.ch9.testsosgi.BootstrapTest - Equinox OSGi

Platform [3.5.0.200811061137] started

18:25:49.641 [main] DEBUG c.a.s.ch9.testsosgi.BootstrapTest - Default framework

bundles :{org.aopalliance,com.springsource.org.aopalliance,1.0.0,
org.junit,com.springsource.junit,3.8.2,
org.objectweb.asm,com.springsource.org.objectweb.asm,2.2.3,
org.slf4j,com.springsource.slf4j.api,1.5.0,
org.slf4j,com.springsource.slf4j.log4j,1.5.0,
org.slf4j,com.springsource.slf4j.org.apache.commons.logging,1.5.0,
org.springframework,spring-aop,2.5.5, org.springframework,spring-beans,2.5.5,
org.springframework,spring-context,2.5.5, org.springframework,spring-core,2.5.5,
org.springframework,spring-test,2.5.5, org.springframework.osgi,log4j.osgi,1.2.15-
SNAPSHOT, org.springframework.osgi,spring-osgi-annotation,1.2.0-m1,
org.springframework.osgi,spring-osgi-core,1.2.0-m1,
org.springframework.osgi,spring-osgi-extender,1.2.0-m1,
org.springframework.osgi,spring-osgi-io,1.2.0-m1, org.springframework.osgi,spring-
osgi-test,1.2.0-m1}
18:25:49.646 [main] INFO  c.a.s.c.t.t.LocalFileSystemIvyRepository - Local Ivy2

repository used: [ivylib]
<OTHER INFO AND DEBUG OUTPUT OMITTED FOR BREVITY>
18:25:50.566 [main] DEBUG c.a.s.ch9.testsosgi.BootstrapTest - Looking for

Spring/OSGi powered bundles to wait for...
OSGi Framework Vendor : Eclipse
OSGi Framework Vendor Version : 1.5.0
OS Name and Version :  Linux-2.6.27

Your first Spring-DM test didn't do all that much, except obtain values from the underlying OSGi testing environment and operating system used to run the test. A more interesting Spring-DM test would consist of guaranteeing a bundle publishes an OSGi service correctly, or the consumption of an OSGi service produces its expected outcome.

As it turns out, from Chapter 7 we have five bundles we can put to the test in order to avoid any surprises once they enter a production environment. So let's get started creating a Spring-DM test class with one of these bundles.

The test will consist of guaranteeing the integrity of the helloworld-db.jar bundle. This particular bundle is charged with providing a connection to a MySQL RDBMS and making it available as an OSGi service for other bundles in the application. Given this purpose, the following test will assert the OSGi service is published correctly and that the service can be used to perform a query against the RDBMS. Listing 9-10 shows the test class for the helloworld-db.jar bundle.

1     package com.apress.springosgi.ch9.testsosgi;

2     import org.springframework.osgi.test.AbstractConfigurableBundleCreatorTests;
3     import org.springframework.osgi.test.provisioning.ArtifactLocator;

4     import java.util.List;
5     import java.util.ArrayList;
6     import java.util.Collections;

7      import org.springframework.core.io.Resource;
8     import org.springframework.core.io.FileSystemResource;

9     import org.osgi.framework.BundleContext;
10    import org.osgi.framework.ServiceReference;

11    import javax.sql.DataSource;
12    import org.apache.commons.dbcp.BasicDataSource;
13    import java.sql.Connection;
14    import java.sql.Statement;
15    import java.sql.ResultSet;

16    import com.apress.springosgi.ch9.testsosgi.testivyprovisions.

LocalFileSystemIvyRepository;

17    public class DataSourceBundleTest extends

 AbstractConfigurableBundleCreatorTests {

18        protected String getRootPath() {
19            return"file:./classes/";
20        }

21        protected ArtifactLocator getLocator() {
22            return new LocalFileSystemIvyRepository();
23        }

24        protected String[] getTestBundlesNames() {
25            List col = new ArrayList();
26            col.add("com.mysql.jdbc, com.springsource.com.mysql.jdbc, 5.1.6");
27            col.add("org.apache.commons, com.springsource.org.apache.commons.dbcp,

 1.2.2.osgi");
28            col.add("org.apache.commons, com.springsource.org.apache.commons.pool,
 1.3.0");
29            return (String[]) col.toArray(new String[col.size()]);
30        }

31        protected Resource[] getTestBundles() {
32            Resource[] repoBundles = locateBundles(getTestBundlesNames());
33            Resource[] testBundles = new Resource[] {
34                new FileSystemResource("dist/ch9/helloworld-db.jar")
35            };
36            List<Resource> allBundles = new ArrayList<Resource>();
37            Collections.addAll(allBundles, repoBundles);
38            Collections.addAll(allBundles, testBundles);
39            return allBundles.toArray(new Resource[] {});
40        }

41         public void testDataSourceService() {
42            waitOnContextCreation("com.apress.springosgi.ch9.db");
43            //The superclass provides access to the testing bundle's context,

which can then get ahold of published services
44            ServiceReference ref = bundleContext.getServiceReference(DataSource.

class.getName());
45            assertNotNull("Service Reference is null", ref);
46            try {
47                DataSource dataSourceService = (DataSource) bundleContext.

getService(ref);
48                assertNotNull("Cannot find the service", dataSourceService);
49                // Start connection and query sequence to the DB using

OSGi-backed service
50                Connection dataSourceConnection = dataSourceService.getConnection();
51                Statement statement = dataSourceConnection.createStatement();
52                ResultSet result = statement.executeQuery("select * from

 HelloWorld where language = 'Spanish'");
53                boolean rs = result.next();
54                if (rs) {
55                    assertEquals("Hola Mundo!",result.getString("message"));
56                } else {
57              throw new Exception("No record in DB belonging to Spanish

 tranlsation");
58                }
59                result.close();
60                statement.close();
61                dataSourceConnection.close();
62            } catch (Exception exc) {
63                exc.printStackTrace();
64            } finally {
65                bundleContext.ungetService(ref);
66            }
67        }
68    }

Just like the earlier test, this class inherits its behavior from Spring-DM's AbstractConfigurableBundleCreatorTests class (Line 17). This test class also overrides the getRootPath (Lines 18 to 20) and getLocator (Lines 21 to 23) methods to suit the particular needs of the project, which is to locate the test class inside the classes directory and locate bundle dependencies in an Apache Ivy repository.

Besides these two methods, which you are already familiar with, there are two new methods, getTestBundlesNames (Lines 24 to 30) and getTestBundles (Lines 31 to 40). These methods are used to load additional bundle dependencies needed to run tests in the Spring-DM testing framework.

The getTestBundlesNames method loads bundles from the ArtifactLocator defined in the test class, which in this case corresponds to a custom ArtifactLocator designed to use an Apache Ivy repository. The format used to define dependencies in the getTestBundlesNames method consists of a String array, with each string following a group, ID, and version notation, where the group, ID, and version are values in line with the conventions used to define dependencies in Apache Ivy and Apache Maven. In Apache Ivy the values for group, ID, and version map to the ivy.xml <dependency> element attributes org, name, and rev, respectively.

The getTestBundlesNames method for this particular test declares org.apache.commons.dbcp, org.apache.commons.pool, and com.mysql.jdbc as prerequisite bundles. This is because all three bundles are needed by the helloworld-db.jar bundle and as a consequence need be installed in order to perform a test on this last bundle.

Since not every bundle needed to run a test will be located in a repository like Apache Ivy or Apache Maven, the getTestBundles method is used to load bundles using a file system route—via the FileSystemResource class. As a consequence, this method fits perfectly for loading the application helloworld-db.jar bundle.

This particular instance of getTestBundles, in addition to loading the helloworld-db.jar bundle using a FileSystemResource instance, also appends the bundles declared in the getTestBundlesNames method. This is due to Spring-DM's testing framework design. In order to use both the getTestBundles and getTestBundlesNames in a test class, the former method needs to explicitly call the latter; otherwise, the bundles declared in getTestBundlesNames are not installed in the OSGi testing environment.

Once all the required bundles for running the test are installed, the first and only test method, testDataSourceService, is executed. This test method will assert that an OSGi DataSource service is available and perform a query against the RDBMS.

The first declaration (Line 42) inside the test method is waitOnContextCreation("com.apress.springosgi.ch9.db"). The use of this statement tells the Spring-DM testing framework to hold the test until the context of a bundle with a symbolic name com.apress.springosgi.ch9.db is created; in this case, the symbolic name corresponds to the helloworld-db.jar bundle.

The waitOnContextCreation method is an important safeguard for performing tests, since it guarantees a test will have access to the bundle context on which the test will be performed. On tests consisting of multiple bundles, this can be especially important since it ensures that certain bundles providing services to other test bundles have their context created first.

The next line in the test class (Line 44) attempts to retrieve a service reference of the type DataSource.class.getName(), which is also equal to javax.sql.DataSource. Note that this service reference is located using the bundleContext.getServiceReference call, which is a standard OSGi method belonging to the org.osgi.framework package. The bundleContext in this case refers to the test bundle created on the fly by the Spring-DM testing framework to execute the test.

Next, you can see the assertNotNull statement (Line 45), which is used to guarantee the prior service reference is not null. By design, the helloworld-db.jar bundle is configured to publish a javax.sql.DataSource service reference, so if this application bundle installed using the getTestBundles method is designed correctly, the assertion will pass; otherwise the assertion and test will fail.

Following this first assertion is a try/ catch block (Lines to 46 to 66) that will perform a query on the RDBMS. The first step consists of obtaining the OSGi service for the javax.sql.DataSource service reference (Line 47). The service reference is obtained using the statement bundleContext.getService(ref), which also corresponds to a standard OSGi method.

Immediately after the service reference is obtained, another assertion statement is made to guarantee that the service is not null (Line 48). Here again, if for some reason the service published by the helloworld-db.jar bundle is not working correctly, the assertion and test will fail.

At this point the test guarantees the OSGi service is published by helloworld-db.jar, but the test can go a step further, executing a query against the RDBMS using this same service. Since the dataSourceService is a javax.sql.DataSource, this test can be performed using the regular JDBC query process: create a Connection object, followed by a Statement object and a ResultSet object.

Since we know beforehand the dataset held in the RDBMS, we also know the query performed against the RDBMS, select * from HelloWorld where language = 'Spanish', should return a certain set of values. In this case, we expect the specified query to return an Hola Mundo! value for the message column. The final assertion in the form of assertEquals (Line 55) guarantees the data obtained from the RDBMS via an OSGi service is the correct data.

Given that this test class belongs to the same package, com.apress.springosgi.ch9.testsosgi, as the earlier test class, by placing it in the same source directory, the same Apache Ivy and Apache Ant configuration files can be used to trigger the execution of the test.

The mechanism for creating test classes for the remaining Hello World application bundles follows this same pattern, with the most variable step being the installation of dependency bundles needed to run the test from either a repository—like Apache Maven or Apache Ivy—or the file system, via the getTestBundlesNames and getTestBundles methods. For example, a test class for the Hello World application web bundle (WAR) would require the installation of Tomcat and a series of additional Spring bundles, as well as the other application bundles, since they are all dependencies for the web bundle (WAR).

As far as the test methods are concerned, the logic in such tests is open ended. As illustrated in this last test class, a test method can use APIs ranging from the OSGi framework to get ahold of services provided by other bundles in the test environment, to JDBC calls that interact with an RDBMS, to any other API required to assert a bundle's logic.

Finally, it's worth mentioning that the AbstractConfigurableBundleCreatorTests class has a few more methods that can be overridden. These range from the getManifestLocation method, used to provide a prebuilt MANIEST.MF file for the test bundle (instead of letting the Spring-DM testing framework generate one for you), to the getConfigLocations method, used to provide a prebuilt application context for the test bundle. Such methods, however, are rarely required to be overridden. You can consult the AbstractConfigurable BundleCreatorTests class's Java docs for more information on these and other methods.

This concludes our exploration into testing bundles using the Spring-DM testing framework, and with it the overall subject of testing Spring and OSGi applications.

In this chapter you learned how testing plays an important role in the overall life cycle of application development, ensuring a class's logic works as expected once in a production environment. In this same context, you explored why Spring-DM eases the creation of tests when an application leverages OSGi.

You then explored how non-OSGi tests—unit and integration with an RDBMS—can be equally applied to a code base that uses OSGi, thanks in part to the decoupling of OSGi logic achieved by using Spring-DM.

Then you continued on to explore the Spring-DM testing framework. You learned how it reduces the amount of work needed to perform tests on OSGi bundles, aiding in the bootstrapping of an OSGi testing environment and packaging test classes into bundles, as well as providing a series of base classes on which to construct tests.

You then created a test class that illustrated the basic procedure for all Spring-DM test classes. You saw how to override a test class's methods to accommodate the needs of a particular project and use an Apache Ivy repository to satisfy the bundle dependencies needed by a test, as well as use Apache Ant to execute Spring-DM tests.

Finally, you created one more test class designed around the application created in Chapter 7. This test class illustrated how a Spring-DM-powered bundle could be loaded into an OSGi testing environment, verifying that its OSGi services were published correctly and that such services were providing logical results.