You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Toni Menzel <to...@okidokiteam.com> on 2010/09/12 00:10:07 UTC
Re Re: Unit testing
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 <be...@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 <ti...@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
>> >>
>> >
>> >
>>
>
Re: Re Re: Unit testing
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <ko...@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 <be...@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 <to...@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 <be...@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 <ti...@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
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >
>
Re: Re Re: Unit testing
Posted by Bartosz Kowalewski <ko...@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 <be...@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 <to...@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 <be...@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 <ti...@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
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>
Re: Re Re: Unit testing
Posted by Bengt Rodehav <be...@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 <to...@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 <be...@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 <ti...@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
> >> >>
> >> >
> >> >
> >>
> >
>
>