ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (AXIOM-311) Improve the Axiom test suite
Date Wed, 06 Apr 2011 23:52:05 GMT


Hudson commented on AXIOM-311:

Integrated in ws-axiom-trunk #388 (See [])
    AXIOM-311: Refactored SOAPFaultCodeTestBase#testSOAP12GetSubCodeWithParser().

> Improve the Axiom test suite
> ----------------------------
>                 Key: AXIOM-311
>                 URL:
>             Project: Axiom
>          Issue Type: Improvement
>            Reporter: Andreas Veithen
>             Fix For: 1.2.12
> axiom-tests contains a rich set of unit tests, but things could still be improved by
applying a common set of tests to both LLOM and DOOM. Indeed the test coverage of DOOM is
much lower than that of LLOM. I already refactored some of the tests so that they are applied
to both OM implementations, but we should push things further.
> One specific problem is that since all tests are in a common Maven module which depends
on both axiom-impl and axiom-dom, it happens that some DOOM tests accidentally use the LLOM
implementation (which is the default). This could be avoided by moving the tests out of axiom-tests
into the axiom-api, axiom-impl and axiom-dom. Looking at the description in axiom-tests/pom.xml,
It seems that this was actually the original intention:
> [quote] The Axiom test suite. This ought to be split into several parts and be made a
part of axiom-api, axiom-impl and axiom-dom. However, that's not as easy as it seems. The
intention is to start with axiom-test and continuosly move parts to the actual projects. [/quote]
> It is indeed true that this is not as easy as it seems. I can see the following difficulties:
> 1) In Maven, the fact that module B depends on module A doesn't imply that the unit tests
of module B can refer to code in the unit tests of module A. If we want to avoid creating
new modules for the test code shared among several other modules, we need to get around this
problem. We had the same issue in Synapse and it can be solved by using the test-jar goal
in maven-jar-plugin which attaches a JAR with the unit test code. It is then sufficient to
add this as a dependency (in scope test) to the other modules.
> 2) We not only need to split the code, but also the test messages and documents in axiom-tests/test-resources.
As with the code, some of these documents would be used by several modules. The problem here
is that the tests don't access them as classpath resources but as files (see AbstractTestCase).
If we change that, i.e. if we load them using Class#getResourceAsStream, then the solution
for item 1 will also solves this problem. But maybe there is a particular reason why AbstractTestCase
uses file access?
> 3) Currently axiom-tests overrides the JavaMail dependency of axiom-api (see WSCOMMONS-417).
If we move the tests to the module to which they apply, we can no longer do this, but I think
it is a bad practice anyway.
> Does anyone see other difficulties that block us from splitting axiom-tests?

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message