You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Bengt Rodehav <be...@rodehav.com> on 2010/09/07 09:10:43 UTC
Unit testing
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?
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...
Best regards,
/Bengt
Re: Unit testing
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks - will do,
/Bengt
2010/9/7 Bartosz Kowalewski <ko...@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 <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: Unit testing
Posted by Bartosz Kowalewski <ko...@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 <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: Unit testing
Posted by 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: Unit testing
Posted by 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: Unit testing
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <da...@yahoo.com>
>
> 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: Unit testing
Posted by David Jencks <da...@yahoo.com>.
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
>