[seam-dev] Arquillian Testsuite structure for Modules

[Ken Finnigan]

Shane,

Jason's correct, the main extrapolation point at the moment is pulling the
container-boms I've created into a location that all modules can use, and
expanding them to include the ones that Dan has put together.

Ken

On Mon, Aug 8, 2011 at 7:33 PM, Jason Porter <lightguard.jp at gmail.com>wrote:

> 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/20110810/6c06927d/attachment-0001.html