Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
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?
Attachments
Issue Links
- is blocked by
-
-
- Closed
-