The container boms should be pulled in. Anything else would be be a bit of a
headache to maintain and make generic enough for everyone to use.
On Mon, Aug 8, 2011 at 17:28, Shane Bryzak <sbryzak(a)redhat.com> wrote:
Ken, I'd like this to be adopted as the standard for all
modules. Which
common dependencies do you think we should put in seam-parent to make it
easier for them?
On 30/07/11 12:16, Ken Finnigan 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-...
- 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.mdout... 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
listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: