You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Aaron Smuts <as...@yahoo.com> on 2005/08/27 03:21:55 UTC

Re: Maven/Spring Testing -- three builds, three config files per project, anthill

FYI, the way I do it:

I use the singleton bean factory locator in my
applications.  I just use Spring for the bean factory
and some programmatic transaction management, not aop
style.   I also used the mock jndi to simulate a
container until I got away from Jboss . . .

For each project, I have three beanRefFactory.xml
(sp?) files: one for prod, one for unit tests, and one
for integration tests.  The latter 2 are in the
test-conf. I also have three normal spring config
files for each app.  They are named according to the
same explicit convention:
integration-test-PROJECTNAME-beanRefFactory.xml, or
unit-test-PROJECTNAME-spring.xml, or
PROJECTNAME-spring.xml.  This keeps everything very
clean and explicit!

The bean ref includes spring files in dependent
projects.  I put the child project's spring config
files last in the bean ref file, so I can override
parent values when needed.  I have 4 layers deep in
some projects.

The distributed artifacts for a particular project
only include the prod file, never the test config. 
The child project is responsible for its own mocks.

The difference between the prod and integration test
files is usually just the datasource.  My projects are
small enough that I don't need to only include a
subset.  If you do, you probably need to shrink your
projects.

For web apps, I expose a static beanConfigFile name
variable on my actions and servlets that allows me to
change what files gets loaded.  For testing non web
components I just get an instance of the beanfactory
locator using the appropriate bean ref file.  This
setup is very simple.  If you extend a base unit test
class or an integration test class, then you can
simplify things further. . . .

This results in some test cod duplicaiton, but there
is no good way around it.  It is often not possible to
reuse the same test for both integration and unit
tests, since you need to setup mocks in the latter.

I use the free version of anthill running in tomcat to
run maven builds.  I just call ant exec with the
appropriate target in my build.xml. (Ha!)  I
parametrize the test include to look like this: 
<include>**/*${test}Test.java</include>  I have three
builds for each project: one that builds the site docs
and runs every 6 hours, one that runs all tests that
runs every 2 hours, and one that runs just unit tests
and runs every hour.  For the unit tests I specify and
argument -Dtest=Unit to just include unit tests.  All
tests are name *IntegrationTest.java, *UnitTest.java,
ManualTest.java, or LoadTest.java.  The last two are
excluded from all automated builds.  This allows me to
use the same project xml for all my continuous
integration needs.  My continuous integration build
also charges my in house maven repository. . . .

I use maven 1.0.2.

Cheers,

Aaron Smuts

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