aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re Re: Unit testing
Date Sat, 11 Sep 2010 22:10:07 GMT
Regarding integration testing in OSGi, let me know if you need any
assistance/help when setting up Pax Exam tests for your Aries Application.

Speaking of that: Glad to see Exam used in Aries!

-- 
*Toni Menzel || **http://okidokiteam.com*

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 <bengt@rodehav.com>:
> 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 <timothyjward@hotmail.com>
>>
>> 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: bengt@rodehav.com
>> > To: aries-user@incubator.apache.org
>> >
>> > 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
>> >>
>> >
>> >
>>
>

Mime
View raw message