[
https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991315#comment-13991315
]
Hudson commented on AXIOM-311:
------------------------------
SUCCESS: Integrated in ws-axiom-trunk #1793 (See
[https://builds.apache.org/job/ws-axiom-trunk/1793/])
AXIOM-311: Refactored testDefaultAttributeType. (veithen: rev 1592900)
*
/webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/llom/OMAttributeTest.java
*
/webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java
*
/webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/attribute/TestGetAttributeTypeDefault.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.16
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org
