[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wss4j-dev
Subject:    [jira] [Updated] (AXIOM-311) Improve the Axiom test suite
From:       "Andreas Veithen (JIRA)" <jira () apache ! org>
Date:       2011-06-23 21:16:47
Message-ID: 1272858814.34561.1308863807631.JavaMail.tomcat () hel ! zones ! apache ! org
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Andreas Veithen updated AXIOM-311:
----------------------------------

    Fix Version/s:     (was: 1.2.12)
                   1.2.13

> 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-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]