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

[Jason T. Greene]

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