You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by David Allen <da...@velograf.com> on 2010/02/17 01:03:02 UTC

iPojo unit testing

I have a component that has a plugin style array of optionally required services:

	@Requires(optional=true)
	Plugin plugins[];

I'm trying to write a unit test for the component and I'm having problems understanding how to implement the dependencies so that iPojo is happy during a maven build. Because I want iPojo to handle the "dynamisism" I did not implement bind/unbind methods to populate the array which leads to a problem when unit testing as there is no way to populate plugin dependencies.

I then created a constructor for initializing the array in tests:

	public TheComponent() { }

	public TheComponent(Plugin... plugins) {
		this.plugins = plugins;
	}

and in my test code call something like:

	TheComponent theComponent = new TheComponent(plugin1, plugin2);

but now iPojo complains that there is no iPojoInstanceManager for that constructor. Is there a way I can use that constructor for injecting dependencies during the tests?

I have also tried to Mock the component using Mockito and receive the following when building:
Caused by: java.lang.ClassNotFoundException: org.apache.felix.ipojo.Pojo
        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)

Both the constructor and mocking work fine when I run the tests manually, it is only when building with the maven ipojo plugin that I get these failures.

Thanks,
David Allen
CTO & Co-Founder
veloGraf Systems
dave@velograf.com




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: iPojo unit testing

Posted by Guillaume Sauthier <Gu...@objectweb.org>.
Hi David

Maybe you can use @Bind / @Unbind on methods to declare your dependecy.
So that ypu can call theses methods from your tests.

--G

David Allen a écrit :
> I have a component that has a plugin style array of optionally required services:
>
> 	@Requires(optional=true)
> 	Plugin plugins[];
>
> I'm trying to write a unit test for the component and I'm having problems understanding how to implement the dependencies so that iPojo is happy during a maven build. Because I want iPojo to handle the "dynamisism" I did not implement bind/unbind methods to populate the array which leads to a problem when unit testing as there is no way to populate plugin dependencies.
>
> I then created a constructor for initializing the array in tests:
>
> 	public TheComponent() { }
>
> 	public TheComponent(Plugin... plugins) {
> 		this.plugins = plugins;
> 	}
>
> and in my test code call something like:
>
> 	TheComponent theComponent = new TheComponent(plugin1, plugin2);
>
> but now iPojo complains that there is no iPojoInstanceManager for that constructor. Is there a way I can use that constructor for injecting dependencies during the tests?
>
> I have also tried to Mock the component using Mockito and receive the following when building:
> Caused by: java.lang.ClassNotFoundException: org.apache.felix.ipojo.Pojo
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
>
> Both the constructor and mocking work fine when I run the tests manually, it is only when building with the maven ipojo plugin that I get these failures.
>
> Thanks,
> David Allen
> CTO & Co-Founder
> veloGraf Systems
> dave@velograf.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
>   



Re: iPojo unit testing

Posted by David Allen <da...@velograf.com>.
Thank you all for the help. It turns out that there was another object in the Test which was trying to instantiate an iPojo controlled class that I did not know about. Once I mocked this other class, the tests turned out great.

Thanks again for the quick responses. I'm really loving iPojo (much more so now that my tests are passing!!),
David

On Feb 17, 2010, at 1:17 AM, Clement Escoffier wrote:

> Hi,
> 
> The issue seems to be that you're executing the test on already manipulated classes. In that case, you should look at integration-test framework as pax exam or junit4osgi.
> 
> Unit Test must happen before the manipulation. For example, let's take this pretty complex component:
> @Component
> public class AdderConsumer {
> 
>    @Requires
>    private AdderService adder;
> 
>    public AdderConsumer() {
>        System.out.println("Using adder service: 1 + 1 = " + adder.add(1, 1));
>    }
> 
>    public AdderConsumer(AdderService adder) {
>        this.adder = adder;
>    }
> 
>    public int add(int a, int b) {
>        return adder.add(a, b);
>    }
> 
> }
> 
> Notice the constructor to inject the (mock) dependency. 
> 
> Then, in my pretty complex test:
> public class AddedConsumerTest {
> 
>    @Test
>    public void testConsumer() {
>        AdderService svc = Mockito.mock(AdderService.class);
>        AdderConsumer adder = new AdderConsumer(svc);
>        Assert.assertEquals(0, adder.add(0, 0));
>    }
> 
> }
> 
> I just mocked the AdderService, inject in in the special constructor, and test the AdderConsumer.
> 
> In my pom, nothing surprising:
> <build>
>    <plugins>
>      <plugin>
>        <groupId>org.apache.felix</groupId>
>        <artifactId>maven-bundle-plugin</artifactId>
>        <version>1.4.3</version>
>        <extensions>true</extensions>
>        <configuration>
>          <instructions>
>            <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
>            <Private-Package>org.apache.felix.ipojo.remote.consumer</Private-Package>
>            <Import-Package>*</Import-Package>
>          </instructions>
>        </configuration>
>      </plugin>
>      <plugin>
> 	      <groupId>org.apache.felix</groupId>
> 	      <artifactId>maven-ipojo-plugin</artifactId>
> 	      <version>1.4.0</version>
> 		  <executions>
>          	<execution>
>            	<goals>
> 	              <goal>ipojo-bundle</goal>
>               </goals>
>          </execution>
>        </executions>
>      </plugin>
>    </plugins>
>  </build>
> 
> When I launch maven on this project, tests are executed before the manipulation (compile, test, maven-bundle-plugin, maven-ipojo-plugin):
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.felix.ipojo.consumer.test.AddedConsumerTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.176 sec
> 
> Results :
> 
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> 
> Now, if you want to test your component in an OSGi environment and see how it reacts to the dynamism 'really'. You can use pax exam and deploy the resulted bundles:
> @Configuration
>    public static Option[] configure() {
> 
> 
> 
>        return  options(
>                felix(),
>                provision(
>                        // Runtime.
>                        mavenBundle().groupId("org.apache.felix").artifactId("org.apache.felix.ipojo").version(asInProject()),
> 			// Your bundles
> 			mavenBundle().groupId("ipojo.tests").artifactId("adder-consumer").version(asInProject()),
> 			mavenBundle().groupId("ipojo.tests").artifactId("adder-provider").version(asInProject())
>                        )), 
> }
> 
> It will launch an OSGi container and deploy the bundles and given you a way to check the behavior.
> 
> Regards,
> 
> Clement
> 
> On 17.02.2010, at 01:03, David Allen wrote:
> 
>> I have a component that has a plugin style array of optionally required services:
>> 
>> 	@Requires(optional=true)
>> 	Plugin plugins[];
>> 
>> I'm trying to write a unit test for the component and I'm having problems understanding how to implement the dependencies so that iPojo is happy during a maven build. Because I want iPojo to handle the "dynamisism" I did not implement bind/unbind methods to populate the array which leads to a problem when unit testing as there is no way to populate plugin dependencies.
>> 
>> I then created a constructor for initializing the array in tests:
>> 
>> 	public TheComponent() { }
>> 
>> 	public TheComponent(Plugin... plugins) {
>> 		this.plugins = plugins;
>> 	}
>> 
>> and in my test code call something like:
>> 
>> 	TheComponent theComponent = new TheComponent(plugin1, plugin2);
>> 
>> but now iPojo complains that there is no iPojoInstanceManager for that constructor. Is there a way I can use that constructor for injecting dependencies during the tests?
>> 
>> I have also tried to Mock the component using Mockito and receive the following when building:
>> Caused by: java.lang.ClassNotFoundException: org.apache.felix.ipojo.Pojo
>>       at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>>       at java.security.AccessController.doPrivileged(Native Method)
>>       at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>       at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
>>       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
>>       at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
>>       at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
>> 
>> Both the constructor and mocking work fine when I run the tests manually, it is only when building with the maven ipojo plugin that I get these failures.
>> 
>> Thanks,
>> David Allen
>> CTO & Co-Founder
>> veloGraf Systems
>> dave@velograf.com
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Re: iPojo unit testing

Posted by Clement Escoffier <cl...@gmail.com>.
Hi,

The issue seems to be that you're executing the test on already manipulated classes. In that case, you should look at integration-test framework as pax exam or junit4osgi.

Unit Test must happen before the manipulation. For example, let's take this pretty complex component:
@Component
public class AdderConsumer {

    @Requires
    private AdderService adder;

    public AdderConsumer() {
        System.out.println("Using adder service: 1 + 1 = " + adder.add(1, 1));
    }
    
    public AdderConsumer(AdderService adder) {
        this.adder = adder;
    }
    
    public int add(int a, int b) {
        return adder.add(a, b);
    }
    
}

Notice the constructor to inject the (mock) dependency. 

Then, in my pretty complex test:
public class AddedConsumerTest {
    
    @Test
    public void testConsumer() {
        AdderService svc = Mockito.mock(AdderService.class);
        AdderConsumer adder = new AdderConsumer(svc);
        Assert.assertEquals(0, adder.add(0, 0));
    }

}

I just mocked the AdderService, inject in in the special constructor, and test the AdderConsumer.

In my pom, nothing surprising:
<build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <version>1.4.3</version>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
            <Private-Package>org.apache.felix.ipojo.remote.consumer</Private-Package>
            <Import-Package>*</Import-Package>
          </instructions>
        </configuration>
      </plugin>
      <plugin>
	      <groupId>org.apache.felix</groupId>
	      <artifactId>maven-ipojo-plugin</artifactId>
	      <version>1.4.0</version>
		  <executions>
          	<execution>
            	<goals>
	              <goal>ipojo-bundle</goal>
               </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

When I launch maven on this project, tests are executed before the manipulation (compile, test, maven-bundle-plugin, maven-ipojo-plugin):
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running org.apache.felix.ipojo.consumer.test.AddedConsumerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.176 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

Now, if you want to test your component in an OSGi environment and see how it reacts to the dynamism 'really'. You can use pax exam and deploy the resulted bundles:
 @Configuration
    public static Option[] configure() {

     

        return  options(
                felix(),
                provision(
                        // Runtime.
                        mavenBundle().groupId("org.apache.felix").artifactId("org.apache.felix.ipojo").version(asInProject()),
			// Your bundles
			mavenBundle().groupId("ipojo.tests").artifactId("adder-consumer").version(asInProject()),
			mavenBundle().groupId("ipojo.tests").artifactId("adder-provider").version(asInProject())
                        )), 
 }

It will launch an OSGi container and deploy the bundles and given you a way to check the behavior.

Regards,

Clement

On 17.02.2010, at 01:03, David Allen wrote:

> I have a component that has a plugin style array of optionally required services:
> 
> 	@Requires(optional=true)
> 	Plugin plugins[];
> 
> I'm trying to write a unit test for the component and I'm having problems understanding how to implement the dependencies so that iPojo is happy during a maven build. Because I want iPojo to handle the "dynamisism" I did not implement bind/unbind methods to populate the array which leads to a problem when unit testing as there is no way to populate plugin dependencies.
> 
> I then created a constructor for initializing the array in tests:
> 
> 	public TheComponent() { }
> 
> 	public TheComponent(Plugin... plugins) {
> 		this.plugins = plugins;
> 	}
> 
> and in my test code call something like:
> 
> 	TheComponent theComponent = new TheComponent(plugin1, plugin2);
> 
> but now iPojo complains that there is no iPojoInstanceManager for that constructor. Is there a way I can use that constructor for injecting dependencies during the tests?
> 
> I have also tried to Mock the component using Mockito and receive the following when building:
> Caused by: java.lang.ClassNotFoundException: org.apache.felix.ipojo.Pojo
>        at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>        at java.security.AccessController.doPrivileged(Native Method)
>        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>        at java.lang.ClassLoader.loadClass(ClassLoader.java:315)
>        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330)
>        at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
>        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:398)
> 
> Both the constructor and mocking work fine when I run the tests manually, it is only when building with the maven ipojo plugin that I get these failures.
> 
> Thanks,
> David Allen
> CTO & Co-Founder
> veloGraf Systems
> dave@velograf.com
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>