On Jan 29, 2006, at 6:12 AM, Prasad Kashyap wrote:

On the list of Dain's "Roamap, tasks and things to do" list,
integration tests that cover servlets, webservices and jms was quite
at the top.
http://www.mail-archive.com/[email protected]/msg16593.html

I would like to propose the following test strategy.

1. Fix existing openejb itests such that they can be reintegrated back
into the builds.

2. Create a testing subproject first in the sandbox that can be used
to test other services and components. This subproject will use maven
2. Integration test is already a phase in the Maven2 lifecycle.

3. Create a new deployment plugin for maven 2 for use by the testing
subproject. A new one is needed because the openejb itests still use
maven 1.

4. As the test suite grows, we can move the subproject from sandbox to
the main branch/trunk. Hopefully by then, openejb will have come out
of it's incubator status for it's itests to join the rest.

What say you all ? Comments, advice, suggestions more than welcome.


This is a good initative.  Couple notes off the top of my head.

A clarification on step 1 would be that we need to run the itest on each assembly we create. Don't mind if they are off by default and run only when we build in continuum, but in each assemblies module after an assembly is built is where they need to execute.

If we wanted to build the new itests in maven 2, that'd be ok. We just need to make sure they run on our assemblies, which use maven 1. We wouldn't need a maven 2 version of our deployment plugin unless we started building the assemblies with maven 2.

If more working itests start showing up, i'd be fine with an itests module next to applications, assemblies, configs, etc.. We'd just want to make sure that the test we add are actually running with the main build and not just a bunch of test-to-get-working-someday like David J. and I did when we tried to create itests about this time in '04.

Thoughts?

-David

Reply via email to