You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Awaragi <pi...@email.com> on 2007/10/02 00:23:20 UTC
multi-module unit testing
Hi All,
i hope that this question was not asked before as I am new to maven and to
this forum. I am trying to build a multi-module project with three modules:
libraries A and B and application C which depends on A and B. Libraries A
and B have their unit testing classes which use a setup class to load
testing resources, setup database connection, etc. This works all fine and
nice for A and B. Now I am in the process of writting unit tests for
application module C and i don't want to do copy/paste of the setup classes
of A and B but I cannot find a way to make unit test classes of C to depend
on unit test classes of A and B.
I thought of moving some of these setup classes to main as a workaround but
then i have to add quite a few test libraries to these modules and to the
web-inf/lib folder of the final war file. Including a database jdbc driver
is not acceptable so this workaround is not the way to go.
Can anyone please help me with this setup?
Pierre
--
View this message in context: http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi-module unit testing
Posted by Francois Fernandes <f....@gmx.net>.
Hi Pierre
Indeed you may have cyclic dependencies.
The solution that I use for this problem is to provide the test-classes
as a speperate artifact.
The maven-jar-plugin provides a convinient way to do so:
http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html
The test jar mojo generates a artifact containing only the classes and
resources out of src/test. The artifact will then be mad available using
the same artifactId and version of the artifact the belong to. As an
addition it will contain a classifier with name "test".
Example:
Both, projects A and B, should contain the following plugin definition:
<project>
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals><goal>test-jar</goal></goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Then add the following dependencies to your project C:
<dependencies>
<dependency>
<artifactId>A</artifactId>
<version>A-version</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
<dependency>
<artifactId>B</artifactId>
<version>B-version</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
</dependencies>
I hope that helps
Francois
Awaragi schrieb:
> Hi Eric,
>
> Thank you for your reply. Your solution is definitly getting me there but I
> am still a little bit confused about dependencies of these projects.
>
> Won't you run into a cirucular dependency issue between common test project
> and the library it support? From example, A, B are lib projects and C is app
> project, currently test setup classes are in A and B and are used by A and B
> test classes. So in theory, say you create a test project T, C will depend
> on A, B and T, T depends on A and B but A and B also depend on T. Maybe I am
> thinking too much? My head is definitly hurting %-|
>
> Thanks again,
> Pierre
>
>
> Eric Daigneault-2 wrote:
>> Hi Pierre,
>>
>> The way I solved this for myself was to create a test project and put all
>> the common test code in it (as normal stuff, not as test stuff) then I
>> used
>> the test project in all other projects as a dependency. This way I have
>> access to the common test stuff. then to ensure that the extra project
>> (jar) does not make it in the final package I declared it as test in it`s
>> dependency scope.
>>
>> Extending the above principle I usually have two such jars for my
>> projects,
>> one that is all the common code used in all tests, there I place all the
>> generic stuff that can be reusable and is not specific. Another I will
>> put
>> all the mocks stubs and other such classes that are specific to the high
>> level project. This way all modules will have access to them and I only
>> code my stuff once. Great thing about this is that I can then code unit
>> tests on the test classes. May sound a bit excessive but when people
>> lives
>> depend on the code you produce a bit of paranoia actually help to protect
>> ones sanity.
>>
>> Of course for the stubs parts, to prevent circular dependencies you may
>> have
>> to separate the interface for your library from the implementation, which
>> in
>> time makes for more stable code. The downside is the multiplication of
>> modules.
>>
>> I hope this helps
>>
>> Éric :D.
>>
>>
>> On 10/1/07, Awaragi <pi...@email.com> wrote:
>>>
>>> Hi All,
>>>
>>> i hope that this question was not asked before as I am new to maven and
>>> to
>>> this forum. I am trying to build a multi-module project with three
>>> modules:
>>> libraries A and B and application C which depends on A and B. Libraries A
>>> and B have their unit testing classes which use a setup class to load
>>> testing resources, setup database connection, etc. This works all fine
>>> and
>>> nice for A and B. Now I am in the process of writting unit tests for
>>> application module C and i don't want to do copy/paste of the setup
>>> classes
>>> of A and B but I cannot find a way to make unit test classes of C to
>>> depend
>>> on unit test classes of A and B.
>>>
>>> I thought of moving some of these setup classes to main as a workaround
>>> but
>>> then i have to add quite a few test libraries to these modules and to the
>>> web-inf/lib folder of the final war file. Including a database jdbc
>>> driver
>>> is not acceptable so this workaround is not the way to go.
>>>
>>> Can anyone please help me with this setup?
>>>
>>> Pierre
>>> --
>>> View this message in context:
>>> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166
>>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: multi-module unit testing
Posted by Awaragi <pi...@email.com>.
Thanks guys for all the usefull insight. I guess there is no easy solution to
this. I would have thought that test inheritance/composition was a common
pattern that maven supported.
I guess I need to carefullu think about how to split modules or perhaps some
very restricted code duplication should relax my head. This is a migration
to maven/spring/struts2 from older technologies so it is a learning process
and I wanted to make sure to adhere to maven philosophy.
Pierre
Eric Daigneault-2 wrote:
>
> Hi Pierre,
>
> It all depends on what you need to share. I discovered that a lot of the
> code I needed to share were things like data set loaders for specification
> tests for example. These are generic by nature and do not require any
> dependencies, thus making isolation in a separate module pretty straight
> forward. However for mocks ans stubs François's solution is more elegant
> where you will use the assembly plugin and generate an extra jar packaging
> all the test stuff together. all in all you will achieve the same end
> result. However you must be careful here on what you share between
> projects
> as it is generally considered bad practice for unit tests to have
> dependencies outside their domain. This being said recoding the same stub
> every time you need to fake a class from another jar is just insane,
> packaging mocks for the classes at the interface of the package within the
> same project and packaging them as separate test jars sounds much better.
>
> This is where I was coming with the solution I proposed earlier, most of
> my
> modules are split in two, one with all the interfaces, factories access
> and
> such and will becomes the API, another for the implementation. APIs can
> have dependencies with other APIs, Implementation will only have
> dependencies to it's API and other APIs. The upside is that it forces me
> to
> think long and hard about what has to be shared, what service provides the
> library, and how it is to be done. Natural corollary from this is that
> the
> test code that needs to be shared is quite easy to determine as other
> projects will have dependency only on the API. This is how I get to
> prevent
> circular dependencies since the tests will have the dame dependency graph
> as
> the rest of the project.
>
> Downside is that the project becomes very large very fast (3 to one split
> in
> modules), and this is where François's proposal becomes interesting, Under
> the same module project I could have it generate all three jars. Sounds a
> bit extreme but since I adopted this Dependencies management through
> dictatorship I found my advil consumption dropped dramatically, especially
> when the interns that work here are warned that some medival torture
> apparatus was rigged to their chairs and wired to the build, I then let
> their imaginations connect the dots if the link with anything but API
> packages. <evil gin>
>
> Anyhow, bit verbose but I hope it helped with your spinning head. ^_^.
>
> Sincerely,
>
> Éric :D.
>
> On 10/2/07, Awaragi <pi...@email.com> wrote:
>>
>>
>> Hi Eric,
>>
>> Thank you for your reply. Your solution is definitly getting me there but
>> I
>> am still a little bit confused about dependencies of these projects.
>>
>> Won't you run into a cirucular dependency issue between common test
>> project
>> and the library it support? From example, A, B are lib projects and C is
>> app
>> project, currently test setup classes are in A and B and are used by A
>> and
>> B
>> test classes. So in theory, say you create a test project T, C will
>> depend
>> on A, B and T, T depends on A and B but A and B also depend on T. Maybe I
>> am
>> thinking too much? My head is definitly hurting %-|
>>
>> Thanks again,
>> Pierre
>>
>>
>> Eric Daigneault-2 wrote:
>> >
>> > Hi Pierre,
>> >
>> > The way I solved this for myself was to create a test project and put
>> all
>> > the common test code in it (as normal stuff, not as test stuff) then I
>> > used
>> > the test project in all other projects as a dependency. This way I
>> have
>> > access to the common test stuff. then to ensure that the extra project
>> > (jar) does not make it in the final package I declared it as test in
>> it`s
>> > dependency scope.
>> >
>> > Extending the above principle I usually have two such jars for my
>> > projects,
>> > one that is all the common code used in all tests, there I place all
>> the
>> > generic stuff that can be reusable and is not specific. Another I
>> will
>> > put
>> > all the mocks stubs and other such classes that are specific to the
>> high
>> > level project. This way all modules will have access to them and I
>> only
>> > code my stuff once. Great thing about this is that I can then code
>> unit
>> > tests on the test classes. May sound a bit excessive but when people
>> > lives
>> > depend on the code you produce a bit of paranoia actually help to
>> protect
>> > ones sanity.
>> >
>> > Of course for the stubs parts, to prevent circular dependencies you may
>> > have
>> > to separate the interface for your library from the implementation,
>> which
>> > in
>> > time makes for more stable code. The downside is the multiplication of
>> > modules.
>> >
>> > I hope this helps
>> >
>> > Éric :D.
>> >
>> >
>> > On 10/1/07, Awaragi <pi...@email.com> wrote:
>> >>
>> >>
>> >> Hi All,
>> >>
>> >> i hope that this question was not asked before as I am new to maven
>> and
>> >> to
>> >> this forum. I am trying to build a multi-module project with three
>> >> modules:
>> >> libraries A and B and application C which depends on A and B.
>> Libraries
>> A
>> >> and B have their unit testing classes which use a setup class to load
>> >> testing resources, setup database connection, etc. This works all fine
>> >> and
>> >> nice for A and B. Now I am in the process of writting unit tests for
>> >> application module C and i don't want to do copy/paste of the setup
>> >> classes
>> >> of A and B but I cannot find a way to make unit test classes of C to
>> >> depend
>> >> on unit test classes of A and B.
>> >>
>> >> I thought of moving some of these setup classes to main as a
>> workaround
>> >> but
>> >> then i have to add quite a few test libraries to these modules and to
>> the
>> >> web-inf/lib folder of the final war file. Including a database jdbc
>> >> driver
>> >> is not acceptable so this workaround is not the way to go.
>> >>
>> >> Can anyone please help me with this setup?
>> >>
>> >> Pierre
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166
>> >> Sent from the Maven - Users mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12993076
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a13002604
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi-module unit testing
Posted by Éric Daigneault <da...@gmail.com>.
Hi Pierre,
It all depends on what you need to share. I discovered that a lot of the
code I needed to share were things like data set loaders for specification
tests for example. These are generic by nature and do not require any
dependencies, thus making isolation in a separate module pretty straight
forward. However for mocks ans stubs François's solution is more elegant
where you will use the assembly plugin and generate an extra jar packaging
all the test stuff together. all in all you will achieve the same end
result. However you must be careful here on what you share between projects
as it is generally considered bad practice for unit tests to have
dependencies outside their domain. This being said recoding the same stub
every time you need to fake a class from another jar is just insane,
packaging mocks for the classes at the interface of the package within the
same project and packaging them as separate test jars sounds much better.
This is where I was coming with the solution I proposed earlier, most of my
modules are split in two, one with all the interfaces, factories access and
such and will becomes the API, another for the implementation. APIs can
have dependencies with other APIs, Implementation will only have
dependencies to it's API and other APIs. The upside is that it forces me to
think long and hard about what has to be shared, what service provides the
library, and how it is to be done. Natural corollary from this is that the
test code that needs to be shared is quite easy to determine as other
projects will have dependency only on the API. This is how I get to prevent
circular dependencies since the tests will have the dame dependency graph as
the rest of the project.
Downside is that the project becomes very large very fast (3 to one split in
modules), and this is where François's proposal becomes interesting, Under
the same module project I could have it generate all three jars. Sounds a
bit extreme but since I adopted this Dependencies management through
dictatorship I found my advil consumption dropped dramatically, especially
when the interns that work here are warned that some medival torture
apparatus was rigged to their chairs and wired to the build, I then let
their imaginations connect the dots if the link with anything but API
packages. <evil gin>
Anyhow, bit verbose but I hope it helped with your spinning head. ^_^.
Sincerely,
Éric :D.
On 10/2/07, Awaragi <pi...@email.com> wrote:
>
>
> Hi Eric,
>
> Thank you for your reply. Your solution is definitly getting me there but
> I
> am still a little bit confused about dependencies of these projects.
>
> Won't you run into a cirucular dependency issue between common test
> project
> and the library it support? From example, A, B are lib projects and C is
> app
> project, currently test setup classes are in A and B and are used by A and
> B
> test classes. So in theory, say you create a test project T, C will depend
> on A, B and T, T depends on A and B but A and B also depend on T. Maybe I
> am
> thinking too much? My head is definitly hurting %-|
>
> Thanks again,
> Pierre
>
>
> Eric Daigneault-2 wrote:
> >
> > Hi Pierre,
> >
> > The way I solved this for myself was to create a test project and put
> all
> > the common test code in it (as normal stuff, not as test stuff) then I
> > used
> > the test project in all other projects as a dependency. This way I have
> > access to the common test stuff. then to ensure that the extra project
> > (jar) does not make it in the final package I declared it as test in
> it`s
> > dependency scope.
> >
> > Extending the above principle I usually have two such jars for my
> > projects,
> > one that is all the common code used in all tests, there I place all the
> > generic stuff that can be reusable and is not specific. Another I will
> > put
> > all the mocks stubs and other such classes that are specific to the high
> > level project. This way all modules will have access to them and I only
> > code my stuff once. Great thing about this is that I can then code unit
> > tests on the test classes. May sound a bit excessive but when people
> > lives
> > depend on the code you produce a bit of paranoia actually help to
> protect
> > ones sanity.
> >
> > Of course for the stubs parts, to prevent circular dependencies you may
> > have
> > to separate the interface for your library from the implementation,
> which
> > in
> > time makes for more stable code. The downside is the multiplication of
> > modules.
> >
> > I hope this helps
> >
> > Éric :D.
> >
> >
> > On 10/1/07, Awaragi <pi...@email.com> wrote:
> >>
> >>
> >> Hi All,
> >>
> >> i hope that this question was not asked before as I am new to maven and
> >> to
> >> this forum. I am trying to build a multi-module project with three
> >> modules:
> >> libraries A and B and application C which depends on A and B. Libraries
> A
> >> and B have their unit testing classes which use a setup class to load
> >> testing resources, setup database connection, etc. This works all fine
> >> and
> >> nice for A and B. Now I am in the process of writting unit tests for
> >> application module C and i don't want to do copy/paste of the setup
> >> classes
> >> of A and B but I cannot find a way to make unit test classes of C to
> >> depend
> >> on unit test classes of A and B.
> >>
> >> I thought of moving some of these setup classes to main as a workaround
> >> but
> >> then i have to add quite a few test libraries to these modules and to
> the
> >> web-inf/lib folder of the final war file. Including a database jdbc
> >> driver
> >> is not acceptable so this workaround is not the way to go.
> >>
> >> Can anyone please help me with this setup?
> >>
> >> Pierre
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166
> >> Sent from the Maven - Users mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12993076
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: multi-module unit testing
Posted by Awaragi <pi...@email.com>.
Hi Eric,
Thank you for your reply. Your solution is definitly getting me there but I
am still a little bit confused about dependencies of these projects.
Won't you run into a cirucular dependency issue between common test project
and the library it support? From example, A, B are lib projects and C is app
project, currently test setup classes are in A and B and are used by A and B
test classes. So in theory, say you create a test project T, C will depend
on A, B and T, T depends on A and B but A and B also depend on T. Maybe I am
thinking too much? My head is definitly hurting %-|
Thanks again,
Pierre
Eric Daigneault-2 wrote:
>
> Hi Pierre,
>
> The way I solved this for myself was to create a test project and put all
> the common test code in it (as normal stuff, not as test stuff) then I
> used
> the test project in all other projects as a dependency. This way I have
> access to the common test stuff. then to ensure that the extra project
> (jar) does not make it in the final package I declared it as test in it`s
> dependency scope.
>
> Extending the above principle I usually have two such jars for my
> projects,
> one that is all the common code used in all tests, there I place all the
> generic stuff that can be reusable and is not specific. Another I will
> put
> all the mocks stubs and other such classes that are specific to the high
> level project. This way all modules will have access to them and I only
> code my stuff once. Great thing about this is that I can then code unit
> tests on the test classes. May sound a bit excessive but when people
> lives
> depend on the code you produce a bit of paranoia actually help to protect
> ones sanity.
>
> Of course for the stubs parts, to prevent circular dependencies you may
> have
> to separate the interface for your library from the implementation, which
> in
> time makes for more stable code. The downside is the multiplication of
> modules.
>
> I hope this helps
>
> Éric :D.
>
>
> On 10/1/07, Awaragi <pi...@email.com> wrote:
>>
>>
>> Hi All,
>>
>> i hope that this question was not asked before as I am new to maven and
>> to
>> this forum. I am trying to build a multi-module project with three
>> modules:
>> libraries A and B and application C which depends on A and B. Libraries A
>> and B have their unit testing classes which use a setup class to load
>> testing resources, setup database connection, etc. This works all fine
>> and
>> nice for A and B. Now I am in the process of writting unit tests for
>> application module C and i don't want to do copy/paste of the setup
>> classes
>> of A and B but I cannot find a way to make unit test classes of C to
>> depend
>> on unit test classes of A and B.
>>
>> I thought of moving some of these setup classes to main as a workaround
>> but
>> then i have to add quite a few test libraries to these modules and to the
>> web-inf/lib folder of the final war file. Including a database jdbc
>> driver
>> is not acceptable so this workaround is not the way to go.
>>
>> Can anyone please help me with this setup?
>>
>> Pierre
>> --
>> View this message in context:
>> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
--
View this message in context: http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12993076
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi-module unit testing
Posted by Éric Daigneault <da...@gmail.com>.
Hi Pierre,
The way I solved this for myself was to create a test project and put all
the common test code in it (as normal stuff, not as test stuff) then I used
the test project in all other projects as a dependency. This way I have
access to the common test stuff. then to ensure that the extra project
(jar) does not make it in the final package I declared it as test in it`s
dependency scope.
Extending the above principle I usually have two such jars for my projects,
one that is all the common code used in all tests, there I place all the
generic stuff that can be reusable and is not specific. Another I will put
all the mocks stubs and other such classes that are specific to the high
level project. This way all modules will have access to them and I only
code my stuff once. Great thing about this is that I can then code unit
tests on the test classes. May sound a bit excessive but when people lives
depend on the code you produce a bit of paranoia actually help to protect
ones sanity.
Of course for the stubs parts, to prevent circular dependencies you may have
to separate the interface for your library from the implementation, which in
time makes for more stable code. The downside is the multiplication of
modules.
I hope this helps
Éric :D.
On 10/1/07, Awaragi <pi...@email.com> wrote:
>
>
> Hi All,
>
> i hope that this question was not asked before as I am new to maven and to
> this forum. I am trying to build a multi-module project with three
> modules:
> libraries A and B and application C which depends on A and B. Libraries A
> and B have their unit testing classes which use a setup class to load
> testing resources, setup database connection, etc. This works all fine and
> nice for A and B. Now I am in the process of writting unit tests for
> application module C and i don't want to do copy/paste of the setup
> classes
> of A and B but I cannot find a way to make unit test classes of C to
> depend
> on unit test classes of A and B.
>
> I thought of moving some of these setup classes to main as a workaround
> but
> then i have to add quite a few test libraries to these modules and to the
> web-inf/lib folder of the final war file. Including a database jdbc driver
> is not acceptable so this workaround is not the way to go.
>
> Can anyone please help me with this setup?
>
> Pierre
> --
> View this message in context:
> http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>