Re: [jbossws-dev] JBossWS testsuite reorganization

Below I'm sharing some notes on the actual testsuite migration to Arquillian, so that anybody can contribute / help on converting the remaining tests: * Server configurations The idea is to keep the set as small as possible, that is to start the minimum number of containers (to save memory); the cxf-tests testsuite currently starts 3 different instances, defined in src/test/etc/arquillian.xml. The first one, with qualifier 'jboss', is the one most of the tests are run against, the second and the third ones are for tests that require a specific instances (in these cases because they need a custom https connector and because they modify the default ws client/endpoint predefined configurations). Keep in mind that tests can be run concurrently (unless they're named -Forked, in which case they're run in a separate process, one at a time). Each server configuration (besides for the first one) needs a port offset, to avoid port clashes; I've been using 10000, 20000, etc. as offsets. I've also set tight memory parameters for the instances that are meant to be used for few or just a single test. The first container instance has the default 'mode', which is 'suite' and means the server is automatically started by Arquillian at the beginning of the testsuite and stopped at the end of the testsuites; the other containers have 'mode = manual' meaning they're not automatically started by Arquillian but the testcases are expected to do that; I've been doing this to defer the memory allocation to when the server is actually needed. The pom.xml for the testsuite project also needs a 'fast' profile to start the same container instances defined in arquillian.xml using the wildfly-maven-plugin; this is needed because Arquillian does not seem to be able to start the containers properly when surefire runs in parallel mode; for this mechanism to work, the 'allowConnectingToRunningServer' option is set to true in arquillian.xml. As far as the standalone.xml setup is concerned, the gmaven-plugin is used to produce a specific standalone configuration for each of the instances that are to be started by Arquillian. We have a groovy script for each configuration that parses the standalone xml tree, modifies it and saves it in a different file. Have a look at the scripts I did for the cxf-tests testsuite to get an idea; the customizations in there are meant to replace the work previously done at runtime by the RemoteDeployer's addSecurityDomain, addHttpsConnector, setSystemProperty methods. * Deployments I've managed to have unique deployment archive names and a 1-1 relationship between archive deployments and testcases. This makes things easier and prevents issues with Arquillian deployment. As we used to have tests relying on the same deployment, I had to either merge tests into a single test class (when it made sense) or duplicate the deployment and use two different names, one for each test. For the -client.jar deployments, that are used to tune the client classpath, I've added a getClientJarPaths() method to JBossWSTest which has to be overridden to return the string path to client deployment on the filesystem. Test methods which need the classpath to be tuned are to be annotated with the @org.jboss.wsf.test.WrapThreadContextClassLoader annotation. See [1] for an example. * Tests Tests are of course to be annotated with @RunWith(Arquillian.class); note that all test methods have to be annotated with @Test. I've used @Deployment(testable=false) for methods providing the deployment most of the times; as a matter of fact we're running all the tests out-of-container so far [3], with @RunAsClient annotation, hence the 'testable = false'. The managed flag is usually not specified (default is true) to let Arquillian manage the deploy/undeploy; the only cases in which we use 'managed = false' is when we need to actually control the deploy/undeploy; a notable example is [2] which uses a special container instance ("ssl-mutual-auth"), starts it in a @Before annotated method and manually deploy the archive on it. Please try to make the less assumption as possible on the deployment publish location, as that really depends on the Arquillian container setup. So, use the @ArquillianResource annotation whenever possible to have the deployment base URL injected in the tests and avoid hard-coding port numbers in the tests. That's all for now, I'll possibly write more if I remember of anything additional worth sharing. Cheers Alessio [1] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/branches/arquillian/modu... [2] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/branches/arquillian/modu... [3] Actually, we do have in-container tests relying on servlets that will be refactored into in-container Arquillian tests in a future effort. On 16/12/14 14:26, Alessio Soldano wrote: -- Alessio Soldano Web Service Lead, JBoss