[seam-dev] Arquillian Testsuite structure for Modules
Ken Finnigan
ken at kenfinnigan.me
Sat Aug 20 19:48:26 EDT 2011
Take a look at the arquillian.XML in i18n as it is there but commented out.
You may also want to set it to log each test into separate file.
Ken
Sent from my iPhone
On Aug 20, 2011, at 19:43, Shane Bryzak <sbryzak at redhat.com> wrote:
> I've gotten a little further, the container is being started now but it seems that dependency injection is broken for some reason, as I'm getting a bunch of NPE's like the following:
>
> Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.035 sec <<< FAILURE!
> testProxiedInterface(org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest) Time elapsed: 0.008 sec <<< ERROR!
> java.lang.NullPointerException
> at org.jboss.seam.solder.test.serviceHandler.ServiceHandlerTest.testProxiedInterface(ServiceHandlerTest.java:52)
>
> Does anyone know if there's an easy way to prevent the test deployment archives from being deleted, so I can examine it?
>
>
> On 21/08/11 09:38, Shane Bryzak wrote:
>>
>> It was my fault, there was a hard-coded arquillian dependency (for an older version of Arquillian) in the Solder impl.
>>
>> On 21/08/11 09:28, John D. Ament wrote:
>>>
>>> Do you have shrinkwrap descriptor api and impl in your reps somewhere?
>>>
>>> John (sent from my DroidX)
>>>
>>> On Aug 20, 2011 7:20 PM, "Shane Bryzak" <sbryzak at redhat.com> wrote:
>>> > I'm just experimenting with this configuration now in Solder, however
>>> > I'm getting the following exception when I run the tests - anyone seen
>>> > this before?
>>> >
>>> > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.244
>>> > sec <<< FAILURE!
>>> > initializationError(org.jboss.seam.solder.test.resourceLoader.ResourceLoaderTest)
>>> > Time elapsed: 0.004 sec <<< ERROR!
>>> > java.lang.NoClassDefFoundError: org/jboss/shrinkwrap/descriptor/api/Node
>>> > at java.lang.Class.getDeclaredConstructors0(Native Method)
>>> > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
>>> > at java.lang.Class.getConstructor0(Class.java:2699)
>>> > at java.lang.Class.getConstructor(Class.java:1657)
>>> > at
>>> > org.jboss.shrinkwrap.descriptor.impl.base.DescriptorImporterBase.from(DescriptorImporterBase.java:145)
>>> > at
>>> > org.jboss.arquillian.impl.bootstrap.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:50)
>>> >
>>> > On 21/08/11 09:18, John D. Ament wrote:
>>> >>
>>> >> I am willing to convert seam JCR to this to see how it runs.
>>> >>
>>> >> John
>>> >>
>>> >> On Aug 20, 2011 7:17 PM, "George Gastaldi" <gegastaldi at gmail.com
>>> >> <mailto:gegastaldi at gmail.com>> wrote:
>>> >> > +1 to the multiple sources idea
>>> >> >
>>> >> > Em 20/08/2011, às 20:01, Shane Bryzak <sbryzak at redhat.com
>>> >> <mailto:sbryzak at redhat.com>> escreveu:
>>> >> >
>>> >> > We could possibly do it by specifying additional source directories
>>> >> for each
>>> >> > profile.
>>> >> >
>>> >> >
>>> >> http://chadthedeveloper.blogspot.com/2008/02/maven2-multiple-source-directories-and.html
>>> >> >
>>> >> > On 21/08/11 08:59, Jason Porter wrote:
>>> >> >
>>> >> > Can we add additional tests with this though for each container?
>>> >> >
>>> >> > Sent from my iPhone
>>> >> >
>>> >> > On Aug 20, 2011, at 16:35, Shane Bryzak <sbryzak at redhat.com
>>> >> <mailto:sbryzak at redhat.com>> wrote:
>>> >> >
>>> >> > That might be one way we can do it - Ken, what do you think about
>>> >> > structuring the test suite like this?
>>> >> >
>>> >> > https://gist.github.com/1155271
>>> >> >
>>> >> >
>>> >> > On 21/08/11 08:27, Jason Porter wrote:
>>> >> >
>>> >> > Maybe something in surefire, or what aslak said on twitter may be
>>> >> helpful.
>>> >> >
>>> >> > Sent from my iPhone
>>> >> >
>>> >> > On Aug 20, 2011, at 16:21, Shane Bryzak <sbryzak at redhat.com
>>> >> <mailto:sbryzak at redhat.com>> wrote:
>>> >> >
>>> >> > I'm currently looking into it.
>>> >> >
>>> >> > On 21/08/11 08:04, Jason Porter wrote:
>>> >> >
>>> >> > Is it possible to add a source directory or test directory?
>>> >> >
>>> >> > Sent from my iPhone
>>> >> >
>>> >> > On Aug 20, 2011, at 15:36, Shane Bryzak <sbryzak at redhat.com
>>> >> <mailto:sbryzak at redhat.com>> wrote:
>>> >> >
>>> >> > Unfortunately that doesn't work - the issue occurs when the artifacts
>>> >> > being unpacked are in the same reactor. See
>>> >> > http://jira.codehaus.org/browse/MDEP-98
>>> >> >
>>> >> > On 21/08/11 01:11, Ken Finnigan wrote:
>>> >> >
>>> >> > If I'm not mistaken, that error is resolved by installing the artifacts.
>>> >> >
>>> >> > The problem is that it doesn't know how to unpack a directory, so
>>> >> the jar
>>> >> > with the test classes needs to be installed for it to work
>>> >> >
>>> >> > Ken
>>> >> >
>>> >> > Sent from my iPhone
>>> >> >
>>> >> > On Aug 20, 2011, at 11:02, Shane Bryzak <sbryzak at redhat.com
>>> >> <mailto:sbryzak at redhat.com>> wrote:
>>> >> >
>>> >> > I've made some progress in this area, so far I've created a few of the
>>> >> > container boms in seam-parent and also started converting the Solder
>>> >> tests
>>> >> > to use the new structure.
>>> >> >
>>> >> > I have run into one issue though - when running the tests I'm
>>> >> encountering
>>> >> > the error below. The reason it hasn't manifested in the International
>>> >> > module is because there was a version mismatch between some of the test
>>> >> > suite artifacts, however if you synchronize them all you get the
>>> >> same error.
>>> >> >
>>> >> > [INFO] Reactor Summary:
>>> >> > [INFO]
>>> >> > [INFO] Seam International Test Suite: Aggregator ......... SUCCESS
>>> >> [1.224s]
>>> >> > [INFO] Seam Container BOMs Aggregator .................... SUCCESS
>>> >> [0.025s]
>>> >> > [INFO] Weld EE Embedded 1.1 Container .................... SUCCESS
>>> >> [0.899s]
>>> >> > [INFO] JBoss AS7 Managed Container ....................... SUCCESS
>>> >> [2.722s]
>>> >> > [INFO] Seam International Test Suite Common .............. SUCCESS
>>> >> [0.376s]
>>> >> > [INFO] Seam International Test Suite: Internals Integration Tests
>>> >> SUCCESS
>>> >> > [0.013s]
>>> >> > [INFO] Seam International Test Suite: Internals Integration Tests Base
>>> >> > SUCCESS [0.743s]
>>> >> > [INFO] Seam International Test Suite: Internals Integration Tests
>>> >> for JBoss
>>> >> > AS FAILURE [2.529s]
>>> >> > [INFO] Seam International Test Suite: Internals Integration Tests
>>> >> for Weld
>>> >> > EE Embedded SKIPPED
>>> >> > [INFO]
>>> >> > ------------------------------------------------------------------------
>>> >> > [INFO] BUILD FAILURE
>>> >> > [INFO]
>>> >> > ------------------------------------------------------------------------
>>> >> > [INFO] Total time: 9.393s
>>> >> > [INFO] Finished at: Sun Aug 21 00:55:38 EST 2011
>>> >> > [INFO] Final Memory: 25M/348M
>>> >> > [INFO]
>>> >> > ------------------------------------------------------------------------
>>> >> > [ERROR] Failed to execute goal
>>> >> > org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack
>>> >> > (unpack-base-tests) on project
>>> >> > seam-international-testsuite-integration-internals-jbossas: Error
>>> >> unpacking
>>> >> > file:
>>> >> >
>>> >> /home/shane/project/seam/international/testsuite/internals/base/target/classes
>>> >> > to:
>>> >> >
>>> >> /home/shane/project/seam/international/testsuite/internals/jbossas/target/test-classes
>>> >> > [ERROR] org.codehaus.plexus.archiver.ArchiverException: The source
>>> >> must not
>>> >> > be a directory.
>>> >> > [ERROR] -> [Help 1]
>>> >> >
>>> >> >
>>> >> > I've spent a little time trying to find a workaround but it seems
>>> >> that this
>>> >> > has been a known bug in Maven for at least 4 years. If anyone wants
>>> >> to take
>>> >> > a look at this and try to figure out a workaround in the meantime
>>> >> please be
>>> >> > my guest.
>>> >> >
>>> >> > Shane
>>> >> >
>>> >> >
>>> >> > 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
>>> >> <http://lists.jboss.org/mailman/listinfo/seam-dev>
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > seam-dev mailing list
>>> >> > seam-dev at lists.jboss.org <mailto:seam-dev at lists.jboss.org>
>>> >> > https://lists.jboss.org/mailman/listinfo/seam-dev
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > seam-dev mailing list
>>> >> > seam-dev at lists.jboss.org <mailto:seam-dev at lists.jboss.org>
>>> >> > https://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
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110820/4e830da9/attachment-0001.html
More information about the seam-dev
mailing list