Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of daigno@gmail.com designates
 209.85.146.183 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=PTDjaL5n4cmVtu3YjtzTVCdOmUuumPOCR1i4bK6pUh5Q6+rTZldKnpBAEhgf33uZNytIVpDsnBslpAhADo8Qv95tB46Gpomu0HtR93htmEk1NsN4NfEmHE/OOVedNwGVjFTPTsddC4YBe1PoPv8xk31ZZ3QCgqdnW52ucVh9TYg=
Message-ID: <5a827c4d0710011538r66f66aa4uc2933a5ec2a1999a@mail.gmail.com>
Date: Mon, 1 Oct 2007 18:38:20 -0400
From: "=?ISO-8859-1?Q?=C9ric_Daigneault?=" <daigno@gmail.com>
To: "Maven Users List" <users@maven.apache.org>
Subject: Re: multi-module unit testing
In-Reply-To: <12989166.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15684_3746534.1191278300662"
References: <12989166.post@talk.nabble.com>

------=_Part_15684_3746534.1191278300662
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 pu=
t
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 hav=
e
to separate the interface for your library from the implementation, which i=
n
time makes for more stable code.  The downside is the multiplication of
modules.

I hope this helps

=C9ric :D.


On 10/1/07, Awaragi <pierrea@email.com> wrote:
>
>
> Hi All,
>
> i hope that this question was not asked before as I am new to maven and t=
o
> 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 an=
d
> 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 drive=
r
> 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#a12989=
166
> 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
>
>

------=_Part_15684_3746534.1191278300662--