[jbossws-dev] JBossWS testsuite reorganization

[Alessio Soldano]

Hi Jim,

On 16/06/14 12:19, Jim Ma wrote:
> As Rosta suggested, the ARQ can help resolve some test issues. We also
> need to write some base or helper class to work better with ARQ to make
> all these things (configure the standalone.xml and change management 
> model
> in runtime) much easier.
Right...

>>
>> Proposals / idea
>> ---------------------
>> I'm listening to proposals to revisit the way the testsuite is run and
>> better address the point above.
>> Something I've been thinking about is relying on Arquillian, similarly
>> to what the WFLY testsuite does. What's not trivial is the fact that we
>> still need to have different version of the Arquillian SPI
>> implementation (that is, different WFLY / EAP versions) used depending
>> on a maven profile specified when running the testsuite; moreover we
>> also need to be able to run against the result of building the latest
>> WFLY master (iow, not a released target for which a
>> wildfly-arquillian-container-xyz is available on the repository).
> Adding profiles for different AS/WF versions looks the thing what we 
> have to do. If WFLY master can publish all these snapshot
> artifacts during the teamcity build, we can consume it from the 
> snapshot repo.
We build WFLY master before running the testsuite on hudson, and build 
wfly locally. That should be enough :-)


>> We
>> could have custom server profile files (standalone-abc.xml) in the
>> jbossws sources for the supported containers to be used for starting
>> specific versions of the containers through Arquillian. The integration
>> tests could be split into groups meant to run against the various
>> different profiles of the selected target container. Pretty much
>> anything we need to customize on the server that can't be done using the
>> Deployer approach can actually be done through a proper profile file (I
>> would still keep the Deployer approach when working to limit the number
>> of profile files to maintain, as there's a lot of stuff in there).
>> Actually, we could even think about having a prepare phase before the
>> actual testsuite that runs given CLI scripts to obtain the desired
>> profile configuration.
>  What about we creating more maven modules/directory for different 
> server profile like WFLY's basic/domain/xts test maven module ?
Yes, that's required too.


>>
>> Next steps
>> ---------------
>> Please provide feedback / ideas. Then we need a plan and eventually
>> jiras created.
>  There could be many work to convert the test archive built with old 
> ant script to new shrinkwrap. Is there any tool exists help us with 
> this ?
Not that I know

>  We can consider to create some tool to allow us migrate to ARQ much 
> easier and faster ?
Not sure, but something might be doable for the Shrinkwrap conversion; 
we should basically parse the Ant build files actually containing the 
libs creation, create a map deployment-archive-name <--> file-contents 
and then go through all the testcases and paste the new code using SW 
for the corresponding deployment-archive.

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss