You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Laurent PETIT <lp...@sqli.com> on 2005/03/14 23:52:15 UTC
junit tests factorisation
Hello there,
I'm trying to split a monobloc demo application I'm writing into
smaller, more usable building blocs.
The current application - assume its name is Prototype - consists of :
- a Service layer
- definitions of DAO interfaces
- 3 different implementations of the DAO interfaces impl.jdbc,
impl.ibatis, impl.speedo
- a set of unit tests (in src/test) for the service layer
- a set of unit tests (in src/test, really speaking dbUnit tests) for
the DAO layer
- for the moment, a conf file in src/conf allows the DAO tests to be
passed on one of the 3 concrete implementations : jdbc, ibatis or speedo.
What I want to do is have separate maven projects for service, DAO specs
(interfaces), DAO impls :
prototype
prototype-dao
prototype-dao-jdbc
prototype-dao-ibatis
prototype-dao-speedo
At the same time, I don't want to duplicate the unit tests for the DAO
layer.
I would have been happy if I could have kept the DAO unit tests with the
DAO specs (interfaces) maven project.
But as I don't want the tests to be jarred with the DAO, and as I think
if I put the tests in the src/test directory, I can't make other project
benefit from it,
the only way I have to mutualize the tests is to create a dao-tests
maven project :
prototype-dao-tests
What I don't like here is that I have to expose the tests at a high
level, just to solve some factorisation problem....
Is this the "best practice" to do it, or do I miss the point somewhere ?
Do you know a better way to solve this *common* (I guess) problem with
project management ?
Thanks in advance for your suggestions,
Regards,
--
Laurent Petit
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: junit tests factorisation
Posted by Laurent PETIT <lp...@sqli.com>.
Eric Pugh wrote:
>I've had this challenge as well. It seems wrong to have unit tests away
>from the unit. However, really you could think of those tests are
>"functional" or "Technology Compatiblity Kit" type of tests.
>
>
I do agree with you that testing with dbUnit crosses the line between
real unit tests and integration tests.
But I think the issue of sharing base abstract test code has its virtues
even in cases that do real unit tests, maybe in the pure domain areas ...
>The DAO tests are focused (I'm guessing) mainly on verifing that the
>DAO's for multiple implementations work the same with all providers.
>And then, for whatever provider specific code you have, those are in
>unit tests bundled in the provider project. So, if you have a
>prototype-tck project, then it doesn't look so bad!
>
>
ok
>Check out Fulcrum Security where I have multiple providers and I verify
>they work regardless of provider:
>http://jakarta.apache.org/turbine/fulcrum/fulcrum-security-api/xref/org/
>apache/fulcrum/security/model/test/package-summary.html
>
>I just tossed the tests into the security-api project which in
>retrospect was icky, and I would have liked to have kept it totally
>separate. Individual projects just extend the abstract test classes to
>provide the startup and shutdown. Although, I think I like your
>approach better, but I wanted an all java solution...
>
I indeed think that I will keep my first thought of haven a separate
project for the tests, which could then be depended upon by the concrete
implementations of my DAOs.
Thanks for the answer,
cu,
--
Laurent
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: junit tests factorisation
Posted by Eric Pugh <ep...@upstate.com>.
I've had this challenge as well. It seems wrong to have unit tests away
from the unit. However, really you could think of those tests are
"functional" or "Technology Compatiblity Kit" type of tests.
The DAO tests are focused (I'm guessing) mainly on verifing that the
DAO's for multiple implementations work the same with all providers.
And then, for whatever provider specific code you have, those are in
unit tests bundled in the provider project. So, if you have a
prototype-tck project, then it doesn't look so bad!
Check out Fulcrum Security where I have multiple providers and I verify
they work regardless of provider:
http://jakarta.apache.org/turbine/fulcrum/fulcrum-security-api/xref/org/
apache/fulcrum/security/model/test/package-summary.html
I just tossed the tests into the security-api project which in
retrospect was icky, and I would have liked to have kept it totally
separate. Individual projects just extend the abstract test classes to
provide the startup and shutdown. Although, I think I like your
approach better, but I wanted an all java solution...
Eric
-----Original Message-----
From: Laurent PETIT [mailto:lpetit@sqli.com]
Sent: Monday, March 14, 2005 10:52 PM
To: Maven Users List
Subject: junit tests factorisation
Hello there,
I'm trying to split a monobloc demo application I'm writing into
smaller, more usable building blocs.
The current application - assume its name is Prototype - consists of :
- a Service layer
- definitions of DAO interfaces
- 3 different implementations of the DAO interfaces impl.jdbc,
impl.ibatis, impl.speedo
- a set of unit tests (in src/test) for the service layer
- a set of unit tests (in src/test, really speaking dbUnit tests) for
the DAO layer
- for the moment, a conf file in src/conf allows the DAO tests to be
passed on one of the 3 concrete implementations : jdbc, ibatis or
speedo.
What I want to do is have separate maven projects for service, DAO specs
(interfaces), DAO impls :
prototype
prototype-dao
prototype-dao-jdbc
prototype-dao-ibatis
prototype-dao-speedo
At the same time, I don't want to duplicate the unit tests for the DAO
layer.
I would have been happy if I could have kept the DAO unit tests with the
DAO specs (interfaces) maven project.
But as I don't want the tests to be jarred with the DAO, and as I think
if I put the tests in the src/test directory, I can't make other project
benefit from it,
the only way I have to mutualize the tests is to create a dao-tests
maven project :
prototype-dao-tests
What I don't like here is that I have to expose the tests at a high
level, just to solve some factorisation problem....
Is this the "best practice" to do it, or do I miss the point somewhere ?
Do you know a better way to solve this *common* (I guess) problem with
project management ?
Thanks in advance for your suggestions,
Regards,
--
Laurent Petit
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org