Thanks - will do, /Bengt
2010/9/7 Bartosz Kowalewski <[email protected]> > Hi Bengt, > > If set up properly, automated integration tests based on Pax Exam will > work out-of-the-box on every machine on which you trigger a Maven > build. Pax Runner started by the Pax Exam Junit test will setup an > embedded instance of an OSGi container. As long as you are able to > embed all components of your app inside a single test - either outside > or inside the OSGi container, everything should work. > > However, when creating those JUnit based itests you'll see that the > process of developing them/making them pass on all machines (no matter > how fast they are, etc.) might be really painful. OSGi container is a > really dynamic environment and you need to code your tests so that > they are ready to handle all timing related issues - different order > of initialization, longer then usual startup time for a specific > bundle, etc. If you take a look at the history of Aries CI build > failures, you'll see what I'm talking about :). There are still some > phantom test failures that happen every 20 builds :). > > Having said that, I highly recommend using Pax Exam :). As other guys > suggested - just take a look at itests projects that are attached to > most of Aries subcomponents. > > Best regards, > Bartek > > 2010/9/7 Bengt Rodehav <[email protected]>: > > Tim, > > Yes, I agree that tests involving a database is really integration > testing > > and not unit testing. Nevertheless it would be convenient to be able to > run > > them without the requirement of an OSGi container. I guess the reason > why I > > was hoping to do this is because it was easy to do in the past (with > > Spring/Hibernate) and I try to opt for the simplest solution. > > Maybe I'll have to rethink on this matter. I agree that testing in the > > container gives a more reliable result. Given that the tests are easy to > > setup and run using Maven I guess it is preferable to do it this > > way.However, I'm a bit disillusioned with past experience regarding > > integration testing in JEE containers. In my experience it is very > complex > > and error prone. Merely having to install, e g Weblogic on every > developers > > workstation is a big hazzle (and in the past also a big cost). > Furthermore, > > deploying, starting and stopping the application server really doesn't > work > > very well at all. The result has been that developers only run a small > > subset of the tests since the setup is too complicated. > > I'll look in more detail how you handle these tests in Aries and see if I > > can steal some of your ideas. > > Thanks, > > /Bengt > > 2010/9/7 Timothy Ward <[email protected]> > >> > >> Hi Bengt, > >> > >> I would like to re-iterate that dependency injection is the best way to > >> get hold of an EntityManager instance (in fact it is the only way to get > a > >> container-managed EntityManager. > >> > >> At this point I would suggest that what you should do depends on your > unit > >> testing policy. Usually unit tests are lightweight and involve plenty of > >> mock objects. I would suggest that actually using OpenJPA and a database > >> isn't really unit testing anymore, as it's far too heavyweight. I would > mock > >> up the EntityManager instance that I passed to my DAO bean in a unit > test > >> environment, and validate that the right calls are made. > >> > >> If you want to to a more complex test (usually called an iTest or > >> integration test in Apache) that includes a database then I would > strongly > >> recommend using the pax runner and setting up an OSGi framework. This > will > >> give you much better validation that the code actually works in situ, > and > >> you can use the real persistence.xml. > >> > >> Regards, > >> > >> Tim > >> > >> > >> ________________________________ > >> > Date: Tue, 7 Sep 2010 09:56:17 +0200 > >> > Subject: Re: Unit testing > >> > From: [email protected] > >> > To: [email protected] > >> > > >> > Thanks for your reply David, > >> > > >> > I will definitely have a look at ops4j pax-runner and how you use it > in > >> > Aries tests. Thanks for the advice. > >> > > >> > Your advice regarding DAO testing is also relevant. I do it in a > >> > similar way today but had some problems with the "out-of-OSGi" > solution > >> > interferring with my "in-OSGi" solution. By using a default > constructor > >> > + dependency injection in OSGi and a constructor taking the entity > >> > manager "in-OSGi" I can probably get rid of that problem. Will look > >> > into it. > >> > > >> > On the same subject (if you bear with me), I forgot to ask about > >> > handling a data source "in-OSGi" and "out-of-OSGi" respectively. > >> > > >> > Prior to deploying my project in an OSGi container, I specified the > >> > JDBC properties in persistence.xml. This doesn't work very well under > >> > OSGi. Instead one specifies what data source service to use and then > >> > deploys a bundle that publishes a data source as a service. The latter > >> > doesn't work well when performing unit tests "out-of-OSGi". > >> > > >> > My strategy so far has been to maintain separate persistence > >> > descriptors for the different scenarios: A persistence.xml for the > unit > >> > tests and a persistence-openjpa.xml for use in the container. The > >> > latter won't be picked up automatically outside a container but can be > >> > specified explicitly using Meta-Persistence in OSGi. It's not an ideal > >> > solution and I'm not yet sure that it will work. Is there a best > >> > practice in this area? > >> > > >> > Thanks, > >> > > >> > /Bengt > >> > > >> > 2010/9/7 David Jencks> > >> > > >> > On Sep 7, 2010, at 12:10 AM, Bengt Rodehav wrote: > >> > > >> >> Lots of mails from me today - just trying to get on top of things.... > >> >> > >> >> I'm investigating the best way to deploy a JPA based application in > >> > OSGi. I've successfully used Karaf and iPojo in combination with Camel > >> > before but JPA seems a bit more complicated. > >> >> > >> >> Using Aries components (jpa, transaction and blueprint) seems to > >> > provide the functionality I need. However, one problem for me is how > to > >> > being able to unit test my services without having to startup a Karaf > >> > instance. In the past I've been using Spring/Hibernate for this > >> > purpose. Spring is very flexible in the sense that I can configure a > >> > test environment for my unit test and still being able to test > services > >> > that uses transactions. > >> >> > >> >> In more detail, my problem is as follows: > >> >> > >> >> I have DAO objects containing persistence logic using JPA. These are > >> > used by my service objects that contains business logic and also > >> > specifies transaction requirements. I can deploy those objects in > >> > Karaf using Aries. However, I don't know how to unit test those > >> > services since they need the presence of Aries. I know that this might > >> > be defined as integration tests (and not unit tests) for that reason > >> > but I would still like a convenient way to execute these tests as part > >> > of my maven build and preferrably without having to deploy Karaf. Is > >> > that possible? > >> >> > >> >> If not, what is the recommended way (best practice) for these kind of > >> > tests? > >> > > >> > Use ops4j pax-runner. There are a bunch of integration tests in aries > >> > that use this. > >> >> > >> >> BTW it is not easy to unit test the DAO objects either since I need > >> > to get hold of an entity manager in completely different ways > depending > >> > on if I'm in an OSGi environment or not. I could take some advice on > >> > this subject as well... > >> > > >> > If you code your DAO objects using constructor dependency injection, > >> > one of the arguments being the EMF, can't you inject it in > >> > blueprint/osgi and simply supply it as a constructor argument in unit > >> > tests? > >> > > >> > If you do some kind of service lookup in your DAO then you will tie it > >> > to whatever lookup technology you are using (service registry for > osgi, > >> > jndi for java ee,....) > >> > > >> > hope this is relevant to what you are asking about... > >> > david jencks > >> > > >> >> > >> >> Best regards, > >> >> > >> >> /Bengt > >> >> > >> > > >> > > >> > > >
