1) "base tests"? As I listed, there is only one class in the a-test project
and that is used during tests by projects which use the proj-a project.
Project proj-a does not depend on this class, so I'm not sure that in this case
the implementation needs to be separate from the API for dependency reasons.
Are there other reasons to separate the API from the implementation?
2) Let's assume for a moment that in project proj-a, the AFactory class is
defined:
public class AFactory {
public static A getInstance() {
// Do some work to create the instance
return ?;
}
}
The matching AFactory class in project a-test would be defined:
public class AFactory {
static A impl;
public static A getInstance() {
return impl;
}
public static setInstance(A touse) {
impl = touse;
}
}
As long as the a-test version of the class is in front of the proj-a version in
the classpath during tests, the unit tests can use the setInstance method to
preload the factory with an appropriate mock object which implements interface
A before the test runs. In this manner, the unit tests in proj-b can simulate
the operation of proj-a without requiring whatever resources are used by class
AImpl. I realize that this is a slightly different use case than what you are
doing, but it is still a dependency of proj-b on test classes from proj-a.
-----Original Message-----
From: Dave Neuer [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 29, 2005 11:39
To: Maven Users List
Subject: RE: Cross-project dependencies on unit test code
Answers:
1) There needs to be an API package so that the Impl and Test packages can both
depend on it (otherwise your base tests would depend on the impl classes, but
your impl depends on the base tests, creating a circular dependancy).
2) How do you ensure that any factory returns any kind of specific
implementation of an interface in general? You have some configuration which
specifies which impl to return at runtime (the config would probably be stored
w/ your tests i.e., src/test/resources). I find Spring quite handy for this
type of setup.
Also, you'd want to define your Mocks in Proj a-test in src/main/java, rather
than src/test/java otherwise they won't get exported.
Dave
-----Original Message-----
From: Allison, Bob [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 28, 2005 1:37 PM
To: Maven Users List; [EMAIL PROTECTED]; Brett Porter
Subject: RE: Cross-project dependencies on unit test code
Here is the pattern I was going to build:
Project proj-a creates a.jar which contains:
-- Interface A which is the API for the jar
-- Class AImpl which implements the API
-- Class AFactory which creates implementations of interface A
Project a-test creates a-test.jar which contains a MockObjects version of class
AFactory which allows unit tests to preload the factory with a mock-object
implementation of interface A to be returned by the factory
Project proj-b uses a.jar, so needs to define a dependency on a.jar with
compile scope and a-test.jar with test scope.
My questions:
1) Is there a reason why the API class (interface A) needs to be in a separate
project from the implementation classes (AImpl and AFactory)?
2) How do I define the dependencies in project proj-b to ensure that the
mock-objects version of AFactory gets used during unit tests?
-----Original Message-----
From: Tim Dysinger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 28, 2005 12:39
To: [EMAIL PROTECTED]; Brett Porter
Cc: Maven Users List
Subject: Re: Cross-project dependencies on unit test code
Ok. Let's say we did it that way. We are still faced with the same
problem with the maven-eclipse-plugin. Maven-eclipse-plugin does not
like having your source and test directories the same.
<sourceDirectory>${basedir}/src/java</sourceDirectory>
<unitTestSourceDirectory>${basedir}/src/java</unitTestSourceDirectory>
I can't do this without using eclipse. The plugin, in this case, would
generate a bogus .classpath file.
Putting the junit code in src/java is the only way I know that maven
will publish your jar so other projects can depened on it. If you just
put your tests in src/test, maven will publish an empty jar and the
dependant project will fail to compile.
-Tim
On Wed, 2005-09-28 at 08:42 +1000, Brett Porter wrote:
> This has been asked 2 or 3 times this week. IIRC someone was going to
> write up their experience doing it? Would anyone like to volunteer to
> add it to the wiki?
>
> - Brett
>
> On 9/28/05, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> > Hi Tim,
> >
> > May you try with something like this :
> > wrapper
> > +- core-api
> > +- core-test (depend only on api)
> > +- core-impl (with some test cases - depends on core-api and core-test
> > the later with scope test)
> > +- use-core-1 (depend on core-impl, depends on core-test at scope test -
> > the test cases must not depend on core-impl's tests)
> > +- use-core-2 (...)
> >
> > Then you move all the common test practices to the core-test project.
> >
> > May that helps.
> >
> > Regards,
> >
> > Raphaël.
> >
> > Tim Dysinger a écrit :
> >
> > >I have a "best practices" question.
> > >
> > >I have a multi-project setup with three sub-projects. Two of the
> > >sub-projects have tests which subclass tests in the "core" project.
> > >However, just having the sub-projects depend on "core" does not expose
> > >the unit test code and the build fails with a compilation error.
> > >
> > >If I put the unit tests into the src/java directory, then the eclipse
> > >plugin generates duplicate source directories "src/java" in
> > >the .classpath file.
> > >
> > >I imagine that I could break out all the tests into other sub-projects
> > >but that seems clumsy and would double the number of projects in my
> > >multi-project setup.
> > >
> > >How do I deal with this elegantly?
> > >
> > >-Tim
> > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
