<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Good post - thanks Ondrej<br>
<br>
how about creating a maven module per purpose (i.e. smoke, basic,
stress, etc). Each module would have the ability to create its own
config via xslt transform. Selecting tests by functional area
would work via package selection (i.e. -Dtest=jms/**/*TestCase).
This means I can run a subset of tests in any given module. The
subset can be as small as one single test.<br>
<br>
If a subset of tests must be run with a different config, we could
have a profile per config, which could be activated by
-Dconfig=foo. The default profile would be activated by not having
a -Dconfig parameter. Each profile has the ability to do config
transformation.<br>
<br>
With this setup you would not have multiple surefire executions.
The large set of integration tests would live in one module (i.e.
basic) and be executed together by default. This module could
contain any number of specialized profiles which select arbitrary
subsets with arbitrary configs. <br>
<br>
cheers<br>
-thomas<br>
</tt><br>
On 12/02/2011 06:47 AM, Ondřej Žižka wrote:
<blockquote cite="mid:1322804839.29770.133.camel@ondra-redhat"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="GENERATOR" content="GtkHTML/3.18.3">
Hi everyone interested,<br>
<br>
there are these motivations for grouping the tests:<br>
<br>
1) Splitting tests by functional area, e.g. jms, jacorb, cmp.<br>
2) Splitting tests by purpose, e.g. smoke, basic, stress etc.<br>
3) Running tests with different configs.<br>
4) Running various groups of tests.<br>
<br>
4) can be done using e.g.
-Dtest=org.jboss.as.test.integration.ejb.*TestCase.java (provided
-Dtest works fine), so I'll drop it from further considerations).<br>
<br>
1-3) is currently done by a combination of modules and Surefire
executions.<br>
The problem with the later is that a failure in one execution
prevents the successive from running.<br>
<br>
Here are options how that can be solved:<br>
<br>
<b>A) Naive solution: Keep status quo, keep tests in the first
execution in a good condition.</b><br>
Pros: * We already have it.<br>
Cons: * It will fail now and then, and people would need an
extra run for the other group, using various params.<br>
<br>
<b>B) Megalomanic solution: Make every combination a maven module.</b><br>
Pros:<br>
* Avaliable right away.<br>
Cons:<br>
* Will result in many modules - e.g. smoke-web, smoke-full,
basic-web, basic-full, ...<br>
* => much harder to maintain, esp. for the product features
(need to distribute stuff to too many pom.xml's).<br>
* Slower testsuite and AS7 build.<br>
* Would not scale for the cases when each test needs a different
config.<br>
<br>
<b>C) Optimistic engineer's solution: Use JUnit's new @Category
and Arquillians ability to restart a server with other config,
based on @ContainerConfig("path-to-config.xml").</b><br>
Pros:<br>
* Simple, clean approach; no pom.xml hell.<br>
* Easy to maintain.<br>
* Easy to reorganize later.<br>
* Would get 3) and 4) out of maven<br>
Cons:<br>
* Arq's impl of @Category is not tested<br>
* We would need to put @Category to all tests<br>
* @ContainerConfig("path-to-config.xml") is not implemented. We
could (mis)use @TargetsContainer and @OperatesOnDeployment.<br>
<br>
<b>Are there others?</b><br>
<b>Did I miss some pros or cons?</b><br>
<b>Which one do you like?</b><br>
<br>
Ondra<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
jboss-as7-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
</pre>
</body>
</html>