I've tried a few different combinations and to me it seems like we're on the right
track functionality-wise.
mvn clean install
-> runs smoke tests as expected
--
mvn clean install -DallTests
-> runs all tests as expected
--
mvn clean install -DallTests=true
-> runs all tests as expected
--
mvn install -pl testsuite/integration/group-smoke/
-Dtest=org.jboss.as.test.smoke.embedded.demos.client.jms.JmsClientTestCase
-> runs the one test as expected
(I did -pl testsute/integration/group-smoke on the assumption that we will be moving to
modules)
--
cd testsuite/integration/group-basic
mvn install
-Dtest=org.jboss.as.test.integration.deployment.classloading.ear.EarClassPath2TestCase
-> runs the one test as expected
--
cd testsuite/integration/group-basic
mvn install
-> Runs those tests as expected
--
Disclaimer: I have not verified that the correct tests are in the correct 'groups'
and that every single test that used to get run runs :-)
From what I can tell, once the test classes get broken out into their
individual modules , which I believe Ondrej says is the next step, we should be ok to run
these from the IDE as well (I have not tried if this works already). I need to go away for
a few hours, when I get back I'll look a bit more at the structure of the
poms/arquillian.xml files etc.
On 23 Nov 2011, at 03:50, Jason T. Greene wrote:
On 11/22/11 5:19 PM, Ondřej Žižka wrote:
>>> There are many problems - I've mentioned them before - like:
>>> * Smoke profile can either be default and need to be disabled
>>> explicitely for any other group; but in that case many people will
>>> forget to disable it which causes inference with other profiles.
>>> Or it would have to be defined explicitely - i.e."no smoke tests run by
>>> default"
>>> * Huge unmaintainable pom.xml
>>> * Impossible to define multiple groups
>>
>> These all sound livable for awhile to me.
> AS 6 sounded livable for a while to some.
>
>>> * Hard to separate web/full or even make all tests run with full
>>> Etc etc. See the resources above, and the issues discussed on as7 list
>>> recently.
>>
>> This works today in master. I just added multiple executions.
> Okay, so it was ready for three days. I understand that coding is more
> fun than merging but what's the point of duplicating work and patching
> unsatisfactory harness?
Because its a priority for beta, and a major refactor is not, especially
one that has little consensus.
>
>>> Compat tests are in different module anyway. This change is refactoring
>>> the integration module. The testsuite/pom.xml is affected too but only
>>> slightly - properties etc.
>>> Do/will the integration submodules need different classpath? BTW slight
>>> differences could be handled by tweaking deps in profiles.
>>
>> Yeah so this is double maintenance, both of these have to be in sync right?
> I don't understand - what's doubled here, opposite to having two
> pom.xml's? It's much less code this way.
The resources/classpath/properties/etc must be duplicated in both the
maven module that "owns" the classes and the group module.
>
>>> Regarding moving the test sources - is there anyone seeing any advantage
>>> in having them all in testsuite/integration/src/test/java ? It looked
>>> quite ellegant solution but if there's really no one liking it,
let's
>>> move it :)
> Seems like you skipped this paragraph, I recommend the last sentence to
> your attention. Following it will take us to "MORE SMALL MODULES".
>
>> Please keep in mind that
>>> some configs will need to be distributed across whole testsuite, and
>>> _every_ config"axis" (databases, IPv6, security,...) will need to
be
>>> reflected in _every_ module. What's now few-lines pom.xml for each
>>> module may become a big ball of mud, pulling in things from parent
>>> pom.xml's.
>>
>> Yeah i think referencing external files is a nice solution to this problem.
> No. You can't externalize pom.xml's code to pass tons of properties to
> surefire and to Arquillian (which needs them duplicated right in pom.xml).
Most of the "axis" entries you have above seem to me to be AS
configuration and arq configuratio which is a separate file.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev