[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027594#comment-16027594 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in Jenkins build axiom-trunk #2860 (See [https://builds.apache.org/job/axiom-trunk/2860/]) AXIOM-311: Remove the axiom-api test-jar. (veithen: rev 1796444) * (edit) axiom/axiom-api/pom.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/additional-element-after-body.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/bodyNotQualified.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/empty-header.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/emtyBodymessage.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/faultelements-with-comment.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/minimalMessage.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/reallyReallyBigMessage.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/soapfault.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap11/whitespacedMessage.xml * (delete) axiom/axiom-api/src/test/resources/soap/soap12 * (edit) axiom/implementations/axiom-dom/pom.xml * (edit) axiom/implementations/axiom-impl/pom.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11 * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/additional-element-after-body.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/bodyNotQualified.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/empty-header.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/emtyBodymessage.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/faultelements-with-comment.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/minimalMessage.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/reallyReallyBigMessage.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/soapfault.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap11/whitespacedMessage.xml * (add) axiom/testing/axiom-testsuite/src/main/resources/soap/soap12 > 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 > > 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16027386#comment-16027386 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in Jenkins build axiom-trunk #2857 (See [https://builds.apache.org/job/axiom-trunk/2857/]) AXIOM-311: Remove redundant test and eliminate dependency between old-tests and the axiom-api test-jar. (veithen: rev 1796374) * (edit) axiom/systests/old-tests/pom.xml * (delete) axiom/systests/old-tests/src/test/java/org/apache/axiom/om/SpacesTest.java * (delete) axiom/systests/old-tests/src/test/resources/spaces.xml * (delete) axiom/systests/old-tests/src/test/resources/spaces2.xml AXIOM-311: Migrate StAXOMBuilderTest. (veithen: rev 1796371) * (delete) axiom/systests/old-tests/src/test/java/org/apache/axiom/om/impl/builder * (edit) axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * (add) axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestClose.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 > > 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.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15271412#comment-15271412 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in axiom-trunk #2685 (See [https://builds.apache.org/job/axiom-trunk/2685/]) AXIOM-311: Remove some old tests for scenarios that are extensively covered by other tests. (veithen: rev 1742325) * axiom/systests/old-tests/src/test/java/org/apache/axiom/om/impl/serializer/OMSerializerTest.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 > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054313#comment-15054313 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in axiom-trunk #2388 (See [https://builds.apache.org/job/axiom-trunk/2388/]) AXIOM-311: Rewrite some test cases so that they don't use AbstractTestCase. (veithen: rev 1719667) * axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenWithLocalName.java * axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenWithName.java AXIOM-311: Eliminate reference to AbstractTestCase. (veithen: rev 1719662) * axiom/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestStandaloneConfiguration.java * axiom/testing/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/builder/web_w_dtd2.xml * axiom/testing/axiom-testsuite/src/main/resources/web_w_dtd2.xml > 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.18 > > > 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14566512#comment-14566512 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in axiom-trunk #2091 (See [https://builds.apache.org/job/axiom-trunk/2091/]) AXIOM-311: Use SOAP 1.2 fault sample from soap-testsuite. (veithen: rev 1682712) * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SampleBasedSOAPTestCase.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/fault/TestGetNodeWithParser.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultcode/TestGetSubCodeWithParser.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetSubCodeNestedWithParser.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetSubCodeWithParser.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetValueAsQNameWithParser.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetValueNestedWithParser.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetValueWithParser.java * /webservices/axiom/trunk/testing/soap-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPSample.java * /webservices/axiom/trunk/testing/soap-testsuite/src/main/resources/test-message/soap12 * /webservices/axiom/trunk/testing/soap-testsuite/src/main/resources/test-message/soap12/fault.xml 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.17 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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14536630#comment-14536630 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in ws-axiom-trunk #2008 (See [https://builds.apache.org/job/ws-axiom-trunk/2008/]) AXIOM-311: Reduce the number of dependencies between axiom-testsuite and axiom-api:tests. (veithen: rev 1678491) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/om/impl/DocumentElementExtractor.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/om/impl/RootWhitespaceFilter.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestCloseWithInputStream.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestCloseWithXMLStreamReader.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestInvalidXML.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/container/DocumentElementExtractor.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/container/OMContainerFactory.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/container/OMElementFactory.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/container/RootWhitespaceFilter.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/document/TestBuild.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildElements.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildren.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenRemove1.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenRemove2.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenRemove3.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenRemove4.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/xpath/AXIOMXPathTestCase.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/resources/invalid_xml.xml * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/builder * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/builder/invalid_xml.xml * /webservices/axiom/trunk/testing/xml-testsuite/src/main/java/org/apache/axiom/ts/xml/XMLSample.java * /webservices/axiom/trunk/testing/xml-testsuite/src/main/resources/org/apache/axiom/ts/xml/bulk/test.xml * /webservices/axiom/trunk/testing/xml-testsuite/src/main/resources/org/apache/axiom/ts/xml/simple.xml 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526511#comment-14526511 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in ws-axiom-trunk #1998 (See [https://builds.apache.org/job/ws-axiom-trunk/1998/]) AXIOM-311: Refactor and simplify the test cases for AXIS2-4791. Also remove the System.out.println calls that pollute the build logs. (veithen: rev 1677571) * /webservices/axiom/trunk/implementations/axiom-impl/src/test/java/org/apache/axiom/om/impl/llom/XMLStreamWriterFilterTest.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/om/impl/XMLStreamWriterFilterTestCase.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/axiom/trunk/testing/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestSerializeWithXmlStreamWriterFilter.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.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14049334#comment-14049334 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in ws-axiom-trunk #1841 (See [https://builds.apache.org/job/ws-axiom-trunk/1841/]) AXIOM-311: Eliminated some old SOAPFaultValue and SOAPFaultText test cases that were checking getText/setText. These methods are defined by OMElement and are checked elsewhere. (veithen: rev 1607160) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPBodyTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultCodeTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultReasonTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultSubCodeTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPTestCase.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/SOAPFaultTextTestBase.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/SOAPFaultValueTestBase.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/impl/dom/SOAPFaultValueTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/impl/llom/SOAPFaultValueTest.java AXIOM-311: Refactored/overhauled some test cases. (veithen: rev 1607154) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultNodeTestBase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultRoleTestBase.java * /webservices/axiom/trunk/modules/axiom-dom/src/test/java/org/apache/axiom/soap/impl/dom/SOAPFaultRoleTest.java * /webservices/axiom/trunk/modules/axiom-impl/src/test/java/org/apache/axiom/soap/impl/llom/SOAPFaultNodeTest.java * /webservices/axiom/trunk/modules/axiom-impl/src/test/java/org/apache/axiom/soap/impl/llom/SOAPFaultRoleTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faultnode * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faultnode/TestGetFaultNodeValue.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faultnode/TestGetFaultNodeValueWithParser.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faultnode/TestSetFaultNodeValue.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faultrole/TestGetRoleValue.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faultrole/TestSetRoleValue.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14049500#comment-14049500 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in ws-axiom-trunk #1842 (See [https://builds.apache.org/job/ws-axiom-trunk/1842/]) AXIOM-311: Refactor the test cases for SOAPFaultText#getLang() and remove test classes that are no longer necessary. (veithen: rev 1607207) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPBodyTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultReasonTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultTestCase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPTestCase.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/SOAPFaultTextTestBase.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/impl/dom/SOAPFaultTextTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/impl/llom/SOAPFaultTextTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faulttext/TestGetLang.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/faulttext/TestGetLangFromParser.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14047273#comment-14047273 ] Hudson commented on AXIOM-311: -- SUCCESS: Integrated in ws-axiom-trunk #1838 (See [https://builds.apache.org/job/ws-axiom-trunk/1838/]) AXIOM-311: * Generalize the TestGetChild/TestSetChild/TestSetChildVersionMismatch test cases so that they can be used to test getters/setters in SOAPEnvelope, SOAPBody, SOAPFaultCode and SOAPFaultSubCode as well. * Remove old test cases made redundant by this change. * Fixed a bug uncovered by the new tests. (veithen: rev 1606606) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultCodeTestBase.java * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultSubCodeTestBase.java * /webservices/axiom/trunk/modules/axiom-dom/src/main/java/org/apache/axiom/soap/impl/dom/soap12/SOAP12FaultCodeImpl.java * /webservices/axiom/trunk/modules/axiom-dom/src/test/java/org/apache/axiom/soap/impl/dom/SOAPFaultCodeTest.java * /webservices/axiom/trunk/modules/axiom-dom/src/test/java/org/apache/axiom/soap/impl/dom/SOAPFaultSubCodeTest.java * /webservices/axiom/trunk/modules/axiom-impl/src/main/java/org/apache/axiom/soap/impl/llom/soap12/SOAP12FaultCodeImpl.java * /webservices/axiom/trunk/modules/axiom-impl/src/test/java/org/apache/axiom/soap/impl/llom/SOAPFaultCodeTest.java * /webservices/axiom/trunk/modules/axiom-impl/src/test/java/org/apache/axiom/soap/impl/llom/SOAPFaultSubCodeTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPElementTypeAdapter.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPElementTypeAdapterFactory.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPFaultChildAdapter.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/fault/TestChildOrder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/fault/TestGetChild.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/fault/TestSetChild.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/fault/TestSetChildVersionMismatch.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/misc * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/misc/GetSetChildTestCase.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/misc/TestGetChild.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/misc/TestSetChild.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/misc/TestSetChildVersionMismatch.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14040971#comment-14040971 ] Hudson commented on AXIOM-311: -- FAILURE: Integrated in ws-axiom-trunk #1820 (See [https://builds.apache.org/job/ws-axiom-trunk/1820/]) AXIOM-311: Eliminate the (partially redundant) CustomBuilderTest and replace it by more meaningful test cases. (veithen: rev 1604861) * /webservices/axiom/trunk/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/builder/CustomBuilder.java * /webservices/axiom/trunk/modules/axiom-api/src/main/java/org/apache/axiom/om/impl/builder/StAXOMBuilder.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/builder/CustomBuilderTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/builder/TestRegisterCustomBuilderForPayload.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/envelope/TestCloneWithSourcedElement1.java * /webservices/axiom/trunk/testsuites/soap-testsuite/src/main/java/org/apache/axiom/ts/soap/TestMessage.java AXIOM-311: Refactored some OMDocument tests. (veithen: rev 1604857) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/om/OMDocumentTestBase.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/builder/TestMalformedDocument.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/document/TestBuild.java AXIOM-311: Refactored a test case for the registerCustomBuilder method. (veithen: rev 1604855) * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/builder/CustomBuilderTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/builder/TestRegisterCustomBuilder.java AXIOM-311: Removed some redundant/irrelevant/disabled test cases. (veithen: rev 1604854) * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMTest.java AXIOM-311: Replaced an old test case for the isComplete method by a more meaningful one. (veithen: rev 1604853) * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMTest.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/element/TestIsCompleteWithParser.java * AXIOM-311: Eliminated the old soapmessage.xml test message and replaced it with TestMessageSet.WSA. * Addressed some cloning issues identified in the process. (veithen: rev 1604852) * /webservices/axiom/trunk/modules/axiom-api/src/test/java/org/apache/axiom/om/TestConstants.java * /webservices/axiom/trunk/modules/axiom-api/src/test/resources/soap/soap11/soapmessage.xml * /webservices/axiom/trunk/modules/axiom-api/src/test/resources/soap/soap12/soapmessage.xml * /webservices/axiom/trunk/modules/axiom-impl/src/main/java/org/apache/axiom/soap/impl/llom/soap12/SOAP12FaultValueImpl.java * /webservices/axiom/trunk/modules/axiom-impl/src/test/java/org/apache/axiom/soap/impl/llom/SOAPImplementationTest.java * /webservices/axiom/trunk/modules/axiom-tests/pom.xml * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMCachingTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMTestCase.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/factory/OMLinkedListImplFactoryTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/builder/CustomBuilderTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/serializer/ElementSerializerTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/serializer/OMSerializerTest.java * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/om/util/OMElementHelperTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestDiscardIncomplete.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestCase.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/TestMessageAdapter.java *
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13663746#comment-13663746 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1552 (See [https://builds.apache.org/job/ws-axiom-trunk/1552/]) AXIOM-311: Simplified the regression test for AXIOM-131. (Revision 1484968) Result = SUCCESS veithen : Files : * /webservices/axiom/trunk/modules/axiom-tests/src/test/java/org/apache/axiom/soap/SOAP11FaultImplConversionTest.java * /webservices/axiom/trunk/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13540990#comment-13540990 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1304 (See [https://builds.apache.org/job/ws-axiom-trunk/1304/]) AXIOM-311: Refactored the test cases for AXIOM-96. (Revision 1426807) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/serializer/OMSerializerTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/misc/TestElementPullStreamAndOMExpansion.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/misc/TestElementPullStreamAndOMExpansion2.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/misc/TestElementPullStreamAndOMExpansion3.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13539938#comment-13539938 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1302 (See [https://builds.apache.org/job/ws-axiom-trunk/1302/]) AXIOM-311: Refactored StaxParserTest. (Revision 1426162) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/StaxParserTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildElementsConsumed.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetXMLStreamReaderWithCaching.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestSerializeAndConsumeConsumed.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/element/purchase-order.xml 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13539964#comment-13539964 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1303 (See [https://builds.apache.org/job/ws-axiom-trunk/1303/]) AXIOM-311: Partially refactored MTOMStAXSOAPModelBuilderTest. (Revision 1426190) AXIOM-311: Refactored XOPRoundtripTest. (Revision 1426175) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/mtom/MTOMStAXSOAPModelBuilderTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/mtom * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/mtom/TestGetXMLStreamReaderMTOMEncoded.java veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/util/stax/xop * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/xop/XOPRoundtripTest.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13539222#comment-13539222 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1298 (See [https://builds.apache.org/job/ws-axiom-trunk/1298/]) AXIOM-311: Refactored a test case. (Revision 1425602) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/AttachmentsTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/xop * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/xop/TestSerialize.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13539262#comment-13539262 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1299 (See [https://builds.apache.org/job/ws-axiom-trunk/1299/]) AXIOM-311: Refactored the regression test for AXIOM-95. (Revision 1425638) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/DefaultNSHandlingTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/serializer/OMSerializerTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/resources/defaultNamespace2.xml * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/misc * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/misc/TestAxiom95.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/misc * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/resources/org/apache/axiom/ts/om/misc/defaultNamespace2.xml 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
Hudson commented on AXIOM-311 Improve the Axiom test suite Integrated in ws-axiom-trunk #1178 (See [https://builds.apache.org/job/ws-axiom-trunk/1178/]) * AXIOM-311: Refactored the unit tests for SOAPFaultCode#getValue() for SOAP 1.1. * Improved the Javadoc of SOAPFaultCode#getValue(). * Streamlined the DOOM implementation of SOAPFaultCode#getValue(). (Revision 1377017) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/soap/SOAPFaultClassifier.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultCodeTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/soap/impl/dom/SOAPFaultCodeImpl.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/soap/impl/dom/soap11/SOAP11FaultCodeImpl.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/main/java/org/apache/axiom/soap/impl/dom/soap12/SOAP12FaultCodeImpl.java * /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/main/java/org/apache/axiom/soap/impl/llom/soap11/SOAP11FaultCodeImpl.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap11/faultcode/TestGetValue.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap11/faultcode/TestGetValueWithParser.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
Hudson commented on AXIOM-311 Improve the Axiom test suite Integrated in ws-axiom-trunk #1179 (See [https://builds.apache.org/job/ws-axiom-trunk/1179/]) AXIOM-311: Refactores some of the SOAPFaultSubCode tests. (Revision 1377084) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/soap/SOAPFaultSubCodeTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetSubCodeNestedWithParser.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetSubCodeWithParser.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetValueNestedWithParser.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/faultsubcode/TestGetValueWithParser.java This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13428643#comment-13428643 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1145 (See [https://builds.apache.org/job/ws-axiom-trunk/1145/]) AXIOM-311: Refactored OMDTDTest. (Revision 1369370) AXIOM-311: Refactored part of DefaultNSHandlingTest. (Revision 1369361) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMDTDTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/resources/dtd.xml * /webservices/commons/trunk/modules/axiom/modules/axiom-testutils/src/main/java/org/apache/axiom/testutils/stax/Normalizer.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testutils/src/main/resources/org/apache/axiom/testutils/conformance/dtd.xml veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/DefaultNSHandlingTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testutils/src/main/resources/org/apache/axiom/testutils/conformance/default-namespace.xml 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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404701#comment-13404701 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1061 (See [https://builds.apache.org/job/ws-axiom-trunk/1061/]) AXIOM-311: Refactored part of StAXSOAPModelBuilderTest. (Revision 1355855) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/soap/impl/builder/StAXSOAPModelBuilderTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap11/builder * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap11/builder/TestBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/builder * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap12/builder/TestBuilder.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404453#comment-13404453 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #1058 (See [https://builds.apache.org/job/ws-axiom-trunk/1058/]) AXIOM-311: Refactored a couple of test cases related to SOAPFaults. (Revision 1355687) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMBodyTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/factory/OMLinkedListImplFactoryTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/factory/TestCreateSOAPFault.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13263163#comment-13263163 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #907 (See [https://builds.apache.org/job/ws-axiom-trunk/907/]) AXIOM-311: Refactored some remaining OMSourcedElement tests. (Revision 1331063) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/test/java/org/apache/axiom/soap/impl/dom/SOAPImplementationTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/test/java/org/apache/axiom/soap/impl/llom/SOAPImplementationTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMSourcedElementTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/ds/WrappedTextNodeOMDataSourceTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestByteArrayDS.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestCharArrayDS.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestInputStreamDS.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/sourcedelement/TestWrappedTextNodeOMDataSourceFromReader.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/headerblock/TestByteArrayDS.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254317#comment-13254317 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #879 (See [https://builds.apache.org/job/ws-axiom-trunk/879/]) AXIOM-311: Refactored the MessagesTest unit tests. (Revision 1326308) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/om/OMTestUtils.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/MessagesTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/dom/MessagesTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/dom/OMDOMTestCase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/dom/OMTestUtils.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/builder/BadInputTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/builder/MessageTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/builder/OMTestUtils.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217688#comment-13217688 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #804 (See [https://builds.apache.org/job/ws-axiom-trunk/804/]) AXIOM-311: Moved the regression test for AXIOM-141 to the new test suite. (Revision 1294381) Result = SUCCESS veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/test/java/org/apache/axiom/soap/impl/dom/SOAPImplementationTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/xpath/XPathAppliedToSOAPEnvelopeTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/xpath * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/xpath/TestXPathAppliedToSOAPEnvelope.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13169946#comment-13169946 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #756 (See [https://builds.apache.org/job/ws-axiom-trunk/756/]) AXIOM-311: Make correct usage of assertions and removed some redundant assertions. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/soap/SOAPFaultTextTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/soap/SOAPFaultValueTestBase.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13140179#comment-13140179 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #658 (See [https://builds.apache.org/job/ws-axiom-trunk/658/]) AXIOM-311: Removed tests for the deprecated MIMEOutputUtils class. For the new API, this is covered by MultipartWriterTest. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/MIMEOutputUtilsTest.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.15 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13118722#comment-13118722 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #575 (See [https://builds.apache.org/job/ws-axiom-trunk/575/]) AXIOM-311: Refactored the DOM tests so that they use the same pattern as the other reusable test suites. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/pom.xml * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/DOMTestCase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/DOMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/builder * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/builder/TestWhitespaceAroundDocumentElement.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/document * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/document/TestAllowedChildren.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/document/TestCreateAttribute.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/document/TestCreateElement.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/document/TestCreateText.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/document/TestDocumentSiblings.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestAppendChild.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestAttributes.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestAttributes2.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestAttributes3.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestAttributes4.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetElementsByTagName.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetElementsByTagNameNS.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetElementsByTagNameRecursive.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetElementsByTagNameWithNamespaces.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetElementsByTagNameWithWildcard.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetNamespaceURIWithNoNamespace.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestGetTextContent.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestRemoveFirstChild.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom-testsuite/src/main/java/org/apache/axiom/ts/dom/element/TestRemoveLastChild.java *
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13118814#comment-13118814 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #577 (See [https://builds.apache.org/job/ws-axiom-trunk/577/]) AXIOM-311: Rationalized the test cases for OMElement#getText() and OMElement#setText(). veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/om/OMElementTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetText.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetTextWithCDATASectionChild.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetTextWithMixedOMTextChildren.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestSetText.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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13118847#comment-13118847 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #579 (See [https://builds.apache.org/job/ws-axiom-trunk/579/]) AXIOM-311: Refactored the remaining test cases in OMElementTestBase. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/om/OMElementTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/test/java/org/apache/axiom/om/impl/dom/ElementImplTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/test/java/org/apache/axiom/om/impl/llom/OMElementTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestAddChild2.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestFindNamespaceByPrefix.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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073155#comment-13073155 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #461 (See [https://builds.apache.org/job/ws-axiom-trunk/461/]) AXIOM-311: Moved some attachments related unit tests from axiom-tests to axiom-api so that we can do a unit test coverage analysis in preparation of AXIOM-326. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/PdfAttachmentStreamingTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/attachments/PartOnFileTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/attachments/PdfAttachmentStreamingTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/attachments/AttachmentsTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/PartOnFileTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/attachments/AttachmentsTest.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070715#comment-13070715 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #458 (See [https://builds.apache.org/job/ws-axiom-trunk/458/]) AXIOM-311: Refactored the test case for AXIOM-299, taking into account the new API defined by AXIOM-353. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/pom.xml * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/builder/TestStandaloneConfiguration.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/OMDTDTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/resources/web_w_dtd2.xml * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/resources/web_w_dtd2.xml 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068947#comment-13068947 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #444 (See [https://builds.apache.org/job/ws-axiom-trunk/444/]) AXIOM-311: Refactored OMFactoryTestBase. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/test/java/org/apache/axiom/om/impl/dom/factory/OMFactoryTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-impl/src/test/java/org/apache/axiom/om/impl/llom/factory/OMFactoryTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/om/OMFactoryTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/factory/TestCreateOMElementWithNullURIAndPrefix.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066410#comment-13066410 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #436 (See [https://builds.apache.org/job/ws-axiom-trunk/436/]) AXIOM-311: Refactored some test cases related to namespace declarations. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestMultipleDefaultNS.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/om/OMElementTestBase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestDeclareDefaultNamespace2.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestChildReDeclaringGrandParentsDefaultNSWithPrefix.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestChildReDeclaringParentsDefaultNSWithPrefix.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestDeclareDefaultNamespace1.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/AxiomTestCase.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064103#comment-13064103 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #430 (See [https://builds.apache.org/job/ws-axiom-trunk/430/]) AXIOM-311: Refactored OMChildrenWithQNameIteratorTest. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-dom/src/test/java/org/apache/axiom/om/impl/dom/OMImplementationTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/traverse/OMChildrenWithQNameIteratorTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenWithName4.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenWithName3.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/AxiomTestCase.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/element/TestGetChildrenWithName2.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13062720#comment-13062720 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #425 (See [https://builds.apache.org/job/ws-axiom-trunk/425/]) AXIOM-311: Refactored OMHeaderTest. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/SOAPTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/header/TestAddHeaderBlock.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/soap/header/TestExamineAllHeaderBlocksWithParser.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/soap/impl/llom/OMHeaderTest.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13062734#comment-13062734 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #427 (See [https://builds.apache.org/job/ws-axiom-trunk/427/]) AXIOM-311: Refactored a couple of unit tests related to OMNamespace. veithen : Files : * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/om/OMNamespace.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestGetNamespaceURI.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestObjectEqualsWithDifferentPrefixes.java * /webservices/commons/trunk/modules/axiom/modules/axiom-tests/src/test/java/org/apache/axiom/om/impl/llom/OMNamespaceImplTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-api/src/test/java/org/apache/axiom/om/impl/OMNamespaceImplTest.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestEquals.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestObjectEqualsWithDifferentURIs.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestEqualsWithNullPrefix.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestObjectEquals.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/OMTestSuiteBuilder.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestHashCode.java * /webservices/commons/trunk/modules/axiom/modules/axiom-testsuite/src/main/java/org/apache/axiom/ts/om/namespace/TestGetPrefix.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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014184#comment-13014184 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #370 (See [https://hudson.apache.org/hudson/job/ws-axiom-trunk/370/]) AXIOM-311: Migrated BadInputTest to the new test suite. 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.12 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014211#comment-13014211 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #371 (See [https://hudson.apache.org/hudson/job/ws-axiom-trunk/371/]) AXIOM-311: Refactored a couple of other test cases. 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.12 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
[jira] [Commented] (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011864#comment-13011864 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #361 (See [https://hudson.apache.org/hudson/job/ws-axiom-trunk/361/]) AXIOM-311: Refactored SOAPRoleTest. 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.12 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
[jira] Commented: (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12982345#action_12982345 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #330 (See [https://hudson.apache.org/hudson/job/ws-axiom-trunk/330/]) AXIOM-311: Refactored the existing SOAPFault unit tests. 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.11 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. - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
[jira] Commented: (AXIOM-311) Improve the Axiom test suite
[ https://issues.apache.org/jira/browse/AXIOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12976829#action_12976829 ] Hudson commented on AXIOM-311: -- Integrated in ws-axiom-trunk #317 (See [https://hudson.apache.org/hudson/job/ws-axiom-trunk/317/]) AXIOM-311: Refactored OMTextTestBase into the new test suite and eliminated a redundant test case. 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.11 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. - To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org
