aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: Re Re: Unit testing
Date Mon, 13 Sep 2010 07:36:59 GMT
Thanks a lot for the advice Bartek!

Yeah, of course I wasn't the first one that ran into this. I think changing
the working directory and use Maven to clean that directory  sounds like a
good approach. I will look into it but first I'll see what options might be
available in Pax Exam 2.

/Bengt

2010/9/13 Bartosz Kowalewski <kowalewski.bartosz@gmail.com>

> Hi,
>
> I guess you can go with approaches if you want to clean the cache:
> 1) use PaxRunnerOptions.cleanCaches()
> 2) change Pax Exam's working dir, i.e. like this
> PaxRunnerOptions.workingDirectory(System.getProperty("user.dir") +
> "/paxrunner/") and configure Maven clean plugin so that it is possible
> to delete this extra directory if you explicitly tell Maven to do so
> (for example by activating a profile)
>
> Oh, and I couldn't agree more - Toni is doing a great job :-).
>
> Bartek
>
> 2010/9/13 Bengt Rodehav <bengt@rodehav.com>:
> > Hi Toni,
> > Glad to see you here :-)
> > When browsing for information about Pax Exam your name came up of course.
> I
> > found an interesting presentation you held about the coming version of
> Pax
> > Exam 2. Sounds really interesting - looking forward to it. Judging from
> the
> > ops4j mailing list you're working fiercly with it at the moment.
> > I've just started looking at Pax Exam thanks to advice from the guys here
> at
> > Aries. I'm beginning to think they're right - it's probably the best way
> to
> > go. I'm now trying to create a good configuration (a couple of
> > configurations actually) and a lenient development process. It's looking
> > good although I haven't seen how it works performance wise yet (when I
> add
> > more test cases and more start/stop of the OSGi container). Apparently
> Pax
> > Exam 2 has a lot to offer in this area. The issues I've had so far are:
> > - Support for Felix 3.0.2. This I've seen is on the way.
> > - Problems with caching of bundles. I've corrected errors in my bundles
> and
> > recompiled but it seems like Pax Exam is using cached versions (under
> > C:\Document and Settings\....). I now delete the cache when I encounter
> > unexplainable problems. I guess caching is necessary to gain performance.
> I
> > think cleaning out the cache (perhaps on every new build if specified)
> > should be an option.
> > Seems like a very useful product and sure beats having to start a JEE
> > container (which often fails), deploy EJB's, run tests, stop the JEE
> > container (which often fails), and so forth.
> > Keep up the good work,
> > /Bengt
> >
> > 2010/9/12 Toni Menzel <toni@okidokiteam.com>
> >>
> >> 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