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

[Ondřej Žižka]

> > 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?


> > 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.


> > 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).


Regards,
Ondra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20111123/86406749/attachment.html