On Fri, Jul 29, 2011 at 20:16, Ken Finnigan <ken@kenfinnigan.me> wrote:

All,

I've committed the work on the Arquillian testsuite infrastructure on the i18n module which can be found here: https://github.com/seam/international/tree/develop/testsuite

Here are some notes on how it's structured and what needs to be done:

API and Impl modules still retain unit tests that don't require container testing
testsuite/common includes Deployment and Library helpers and anything that would be common to multiple types of testsuites, such as internals, smoke, etc

The helpers from this module could potentially be pulled up into a common module for all, but that may introduce complexity in trying to use it in each module so may be best to leave it there for the moment and see how it goes

testsuite/container-boms contains the container definition for weld ee embedded and AS7. Others can be found at https://github.com/mojavelinux/arquillian-showcase/tree/master/container-boms

One of the first things that needs to happen is these container-boms need to be created in a seam parent module of some kind such that each module can utilize them without having to replicate the content directly

testsuite/internals/base contains the test classes that used to be within impl. For i18n I was able to leave the entirety of the test classes in the bases module and simply explode it into the target/test-classes directory of the testsuite/internals/${container} modules as part of the integration-test phase.

To make it easier to then explode the jar built from this module into sub modules, the test classes and resources actually need to be in src/main. As we don't plan using the jar built from this for anything other than testing it's not an issue.

container tests are only activated on the integration-test phase and skipped on the basic test phase
https://github.com/seam/international/blob/develop/testsuite/README.md outlines all the proposed types of suites that testsuite can contain. I believe an initial first step should be to move the existing container tests, or create some, for the internals module. Over time we can then look to flesh out the testsuite with additional types such as smoke, cluster, api, etc

One area that I haven't looked at yet is code coverage given that the tests are further spread than previously. I'm hoping that it will be relatively easy to amalgamate all the coverage data to produce a single report.

Any questions about this please let me know.

Ken

_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev