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