[jboss-as7-dev] Testsuite modularization? // Re: Testsuite refactor

[Kabir Khan]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev