[shale] Maven, Cargo and integration testing

[Wendy Smoak <ws...@gmail.com>]

The Shale Blank app is now set up to run its integration tests.

  http://svn.apache.org/viewvc?rev=412639&view=rev

The includes/excludes are working (thanks David!) and we're using the
Cargo Java API to start and stop Tomcat.  (Yesterday's experiment with
the Cargo plugin didn't work out, the inherited config from the
shale-apps parent pom was causing it to try to start Tomcat twice.)

Surefire is bound to the 'test' phase by default, so it runs then with
**/systest/** excluded.

There is an additional execution of Surefire bound to the
integration-test phase, where it runs only the integration tests.

Craig, can you please try 'mvn install -Pmyfaces,itest' from
shale-blank (or above) and let me know if this does what you want?
(You'll either need 'cargo.tomcat5x.home' configured in settings.xml,
or with -D on the command line.)

This app has only one test so it doesn't matter too much, but usually
the code to start and stop the container goes in a TestSetup class.  I
put it directly in the test case to keep things as simple as possible
at first.

Thanks,
-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Maven, Cargo and integration testing

[Wendy Smoak <ws...@gmail.com>]

\On 6/8/06, Craig McClanahan <cr...@apache.org> wrote:

> I've seen that convention, but have a question for you ... since the unit
> tests for webapps built from these examples are going to use the mock
> objects in the Shale Test Framework anyway, what would you think of having a
> convenience abstract base class in shale-test (probably a subclass of
> AbstractHtmlUnitTestCase) that embedded the container startup/shutdown
> stuff?  It would likely need some system properties to specify the container
> id (default to "tomcat5x") and the WAR to be tested, but this approach would
> save having to construct a customized TestSetup class in every webapp
> project.

I'd definitely like to see something that can be reused.  Subclassing
AbstractHtmlUnitTestCase to add 'start' and 'stop' methods works, but
limits you to only using it with HtmlUnit-- and if you used
setUp/tearDown, you would be starting and stopping the container for
each testXxx method.

I'm working with o.a.s.test.cargo.CargoTestSetup now.  This is using
Cargo's 'generic' Java API [1], so it should be possible to start any
container that Cargo supports, and then to run the same tests in
multiple containers simply by varying the system properties.

[1] as opposed to the strongly typed API, nothing to do with Java SE 5 generics.

-- 
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Maven, Cargo and integration testing

[Craig McClanahan <cr...@apache.org>]

On 6/7/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> The Shale Blank app is now set up to run its integration tests.
>
>   http://svn.apache.org/viewvc?rev=412639&view=rev
>
> The includes/excludes are working (thanks David!) and we're using the
> Cargo Java API to start and stop Tomcat.  (Yesterday's experiment with
> the Cargo plugin didn't work out, the inherited config from the
> shale-apps parent pom was causing it to try to start Tomcat twice.)
>
> Surefire is bound to the 'test' phase by default, so it runs then with
> **/systest/** excluded.
>
> There is an additional execution of Surefire bound to the
> integration-test phase, where it runs only the integration tests.
>
> Craig, can you please try 'mvn install -Pmyfaces,itest' from
> shale-blank (or above) and let me know if this does what you want?
> (You'll either need 'cargo.tomcat5x.home' configured in settings.xml,
> or with -D on the command line.)


That works really slick ... thanks!

This app has only one test so it doesn't matter too much, but usually
> the code to start and stop the container goes in a TestSetup class.  I
> put it directly in the test case to keep things as simple as possible
> at first.


I've seen that convention, but have a question for you ... since the unit
tests for webapps built from these examples are going to use the mock
objects in the Shale Test Framework anyway, what would you think of having a
convenience abstract base class in shale-test (probably a subclass of
AbstractHtmlUnitTestCase) that embedded the container startup/shutdown
stuff?  It would likely need some system properties to specify the container
id (default to "tomcat5x") and the WAR to be tested, but this approach would
save having to construct a customized TestSetup class in every webapp
project.

Craig

Thanks,
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>