[seam-dev] Arquillian Testsuite structure for Modules

[Jason Porter]

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 at 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-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.mdoutlines 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 at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>


-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110808/f79b3d36/attachment.html