[jbossws-dev] JBossWS testsuite reorganization

[Alessio Soldano]

On 24/11/14 10:45, Jim Ma wrote:
> On 11/17/2014 07:04 PM, Alessio Soldano wrote:
>> Five months after I started this thread, I finally come back to it with
>> the result of some additional Arquillian investigation I did at the end
>> of last week and a plan for dealing with the reorganization:
>>
>> - we'll be using the wildfly-arquillian-container-managed integration
>> - we'll have multiple standalone.xml server configurations for testing;
>> I plan to provide a solution for avoiding maintaining many confs,
>> basically deriving them from the current container one (either by
>> running CLI commands or by applying XSL transformations). The multiple
>> configurations are required for any test that needs e.g. a custom https
>> connector
>   Are we going to use @ServerSetup to apply change with CLI for 
> arquillian testcase ?

@ServerSetup is a wildfly specific class and I'd really avoid having 
container specific compile time dependencies in our test sources.
In any case, after having talked with Rostislav on IRC, I've decided to 
use a groovy script based approach; that allows direct and easy editing 
of the xml conf files (moreover it's more intuitive then CLI and 
maintainable from a QE point of view).

Cheers
Alessio

>> - we'll be using the 'class' Arquillian container mode for any test
>> requiring a custom server configuration (each test is going to have its
>> own server configuration); all remaining tests will use the default
>> (suite) container mode
>> - all @Deployment will have 'managed=true', except for very few and
>> special cases
>> - all @Deployment will initially have 'testable=false' and all @Test
>> methods will also be @RunAsClient annotated; later we will see if we can
>> re-write some of the tests meant to run in-container which are currently
>> using custom mechanisms (ejb3 / servlet client deployments).
>> - we'll have a convention requiring deployment names to be unique (IOW,
>> no more deployments used by multiple tests); there're are currently few
>> deployments used in more then a test, but that causes more problems then
>> benefits (also consider we could now avoid writing the actually jar/war
>> to the filesystem by default)
>> - we'll probably have a mechanism in the build to automatically retrieve
>> the specified version of WildFly, clone it, generate the various
>> standalone.xml, update the ws stack on it and finally have the testsuite
>> run. No more need for 2 builds (ant + maven) for deploying the stack
>> first and testing it afterwards
>   +1. This will be a big improvement in jbossws5. We can look at 
> update ws stck with jboss module layer path setting or  running 
> jbossas instance with the maven GAV reference module.xml.
>> - we won't need the RemoteDeployer stuff anymore ;-)
>  +1.
>>
>> Cheers
>> Alessio
>>
>


-- 
Alessio Soldano
Web Service Lead, JBoss