[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070837#comment-13070837 ]
Hudson commented on AXIOM-311: ------------------------------ Integrated in ws-axiom-trunk #460 (See [https://builds.apache.org/job/ws-axiom-trunk/460/]) AXIOM-311: Refactored another test case. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/node/TestDetachFirstChild.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java > Improve the Axiom test suite > ---------------------------- > > Key: AXIOM-311 > URL: https://issues.apache.org/jira/browse/AXIOM-311 > Project: Axiom > Issue Type: Improvement > Reporter: Andreas Veithen > Fix For: 1.2.13 > > > 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: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org