Improve the Axiom test suite
----------------------------
Key: WSCOMMONS-419
URL: https://issues.apache.org/jira/browse/WSCOMMONS-419
Project: WS-Commons
Issue Type: Improvement
Components: AXIOM
Reporter: Andreas Veithen
Fix For: Axiom 1.2.9
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.
-
You can reply to this email to add a comment to the issue online.
