aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Unit testing
Date Wed, 08 Sep 2010 07:10:01 GMT
Thanks - will do,

/Bengt

2010/9/7 Bartosz Kowalewski <kowalewski.bartosz@gmail.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