maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allison, Bob" <robert.alli...@qwest.com>
Subject RE: Cross-project dependencies on unit test code
Date Fri, 30 Sep 2005 12:48:26 GMT
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:dneuer@BodyMedia.Com] 
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:robert.allison@qwest.com] 
Sent: Wednesday, September 28, 2005 1:37 PM
To: Maven Users List; raphaelpieroni@gmail.com; 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:tim05@supplychainge.com] 
Sent: Wednesday, September 28, 2005 12:39
To: raphaelpieroni@gmail.com; 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 <raphaelpieroni@gmail.com> 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: 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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


---------------------------------------------------------------------
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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message