[seam-dev] Arquillian update
John D. Ament
john.d.ament at gmail.com
Sun Jul 10 13:35:29 EDT 2011
So what exactly is this? Is this a new structure to support testing?
Here's something I'm interested in. I want to be able to test seam JMS in
an SE type of environment, potentially with starting the JMS server in the
same VM or a separate VM. Part of this requires special modules in Seam JMS
that connect to remote JMS providers, some of this requires special testing
scenarios. Ideally, I would want to run the full test suite repeatedly for
each matching pair. For example:
Seam JMS + OWB + Apache ActiveMQ
Seam JMS + Weld + Hornetq
Seam JMS + Weld + OpenMQ
Is this approach attainable through this setup?
John
On Fri, Jul 8, 2011 at 12:11 PM, Jason Porter <lightguard.jp at gmail.com>wrote:
> I'm liking #3
>
> Sent from my iPhone
>
> On Jul 8, 2011, at 9:28, Ken Finnigan <ken at kenfinnigan.me> wrote:
>
> I've been doing some further thinking around this over the last couple of
> days and have come up with 3 possible structures (there are undoubtedly more
> but that is as far as my brain got!):
>
> 1) The original idea below. ie.
> \testsuite
> \api
> \internals
> \smoke
>
> This setup requires each container, and version there of, to be a separate
> profile. Container specific tests can be excluded with surefire.
>
> This does get quite messy quickly if there are lots of containers, and lots
> of container specific tests that need to be written (ie. lots of exclusions
> in profiles for tests you don't want to run)
>
> 2) More along the lines of Seam Persistence. ie.
> \testsuite
> \base
> \jboss
> \weld-embedded
> \jetty
>
> Each version of a container will have their own profile within a container
> module.
>
> This nicely breaks down the containers, but makes it difficult to know what
> pieces of a module (ie. API, internals, etc) are being tested on each
> container.
>
> 3) A hybrid approach ie.
> \testsuite
> \base or common
> \internals
> \base
> \jboss
> \jetty
>
> We could either go with a base/common module at the root of testsuite,
> which would hold utilities for artifact creation and all common tests or
> base tests for all modules, and/or a base/common for each submodule (ie.
> api, internals). Could take either approach, but a single base/common at
> the testsuite root may make it simpler.
>
> Each container module would then have a profile for each version, with the
> version of a container that you want to test as part of builds set to be
> active by default.
>
>
> I'm personally leaning towards 3 as it gives us a breakdown of types of
> testing, api, internals, smoke, cluster, etc while also providing a
> breakdown of container specific test requirements.
>
> Note: All pure unit tests that do not require a container would still
> remain in the appropriate module, ie. api or impl, of the project.
>
> Any other options anyone can think of, or tweaks to any of the above
> options?
>
> What does everyone think?
>
> Ken
>
>
> On Wed, Jul 6, 2011 at 1:43 PM, Jason Porter < <http://lightguard.jp>
> lightguard.jp@ <http://gmail.com>gmail.com> wrote:
>
>> Adding the rest of the list as I think we're nearing the point we want
>> some more feedback.
>>
>> On Wed, Jul 6, 2011 at 10:35, Ken Finnigan < <ken at kenfinnigan.me>
>> ken at kenfinnigan.me> wrote:
>>
>>> Nasty, read the irc log, not nice at all on AS7 part!
>>>
>>> At the moment I have a structure similar to persistence, but more
>>> following AS7. ie:
>>>
>>> \module_parent
>>> \api
>>> \impl
>>> \testsuite
>>> \api
>>> \benchmark
>>> \clustering
>>> \internals
>>> \smoke
>>> \stress
>>>
>>
>> I like the ideas, but I think the structure should be along the lines of
>> the containers (perhaps in addition to, if we're going to test things like
>> clustering and perf).
>>
>>
>>> Idea being that pure unit tests (ie. no container) remain within either
>>> api/impl modules, then any container testing falls within the testsuite
>>> somewhere. Default test only runs api, internals and smoke, others are
>>> picked up by a profile.
>>>
>>
>> Having the different containers be different test modules also gets us
>> away from having to rely on a profile (so you could run each set of tests in
>> one go instead of multiple invocations or lots of profiles).
>>
>>
>>> At present most of these folders are just ideas about the kinds of tests
>>> we could do (along the AS7 lines), but they seemed appropriate. Existing
>>> i18n module tests are now in internals for testing the implementation. I
>>> see smoke as being more comprehensive tests covering combined use of
>>> features in the module, and quite possibly integration with other modules
>>> too.
>>>
>>
>> I do kind of like the idea of all the tests being inside the test suite,
>> but I'm also okay with basic unit tests living in api and impl. I think we
>> probably need to do some lifecycle tweaking and have those tests under the
>> testsuite run under the integration phase like Solder.
>>
>>
>>> Which container is run is then all down to profile. Not sure whether to
>>> continue with embedded weld being the default container that is run when no
>>> profile is specified, or to force a profile to be specified for any
>>> container testing.
>>>
>>> Also had another thought today as to whether the poms for the test
>>> modules should define dependencies, or whether dependent libraries should be
>>> added directly to deployment artifact as library to prevent unintended
>>> libraries from appearing on test classpath.
>>>
>>
>> If we go with test modules instead of profiles this becomes a non issue as
>> they'd just be test deps for the module.
>>
>> Thoughts?
>>>
>>>
>>>
>>> On Wed, Jul 6, 2011 at 11:35 AM, Jason Porter < <http://lightguard.jp>
>>> lightguard.jp@ <http://gmail.com>gmail.com> wrote:
>>>
>>>> Very cool. I got stuff working for catch last night too, but there is a
>>>> problem if you're testing deployment errors. It's actually an AS7 and
>>>> Arquillian issue. I've opened JIRA tickets about both. I think what we'll
>>>> want to do is set up testing similar to what Stuart has done in Persistence
>>>> with multiple modules. We'll eventually want to test in (probably) embedded
>>>> weld (it's runs quickly, could probably be like a smoke test), JBoss AS7,
>>>> AS6, GF 3.1, Resin and an OWB container or embedded OWB. Not all of those
>>>> containers work right now but then we really could say we know it all works
>>>> on each CDI impl.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jul 6, 2011, at 7:44, Ken Finnigan < <ken at kenfinnigan.me>
>>>> ken at kenfinnigan.me> wrote:
>>>>
>>>> I actually "stole" some day job time to try at work as I thought the
>>>> problem might be caused by the local build of as7 I had in my repo, but that
>>>> wasn't it.
>>>>
>>>> Figured out the problem I was having with the aether class not being
>>>> found was caused by the arquillian junit container dependency being
>>>> specified in a parent pom, and then the managed container being specified in
>>>> the pom running the tests, which meant Maven decided the versions of the
>>>> jars in the pom running the tests should take precedence.
>>>>
>>>> Adding the junit container dependency to the pom running the tests fixed
>>>> that problem.
>>>>
>>>> Should be able to finish up the test setup some time tonight to then
>>>> forward to the mailing list for review.
>>>>
>>>> Ken
>>>>
>>>> On Tue, Jul 5, 2011 at 11:13 PM, Jason Porter < <http://lightguard.jp><http://lightguard.jp>
>>>> lightguard.jp@ <http://gmail.com> <http://gmail.com>gmail.com> wrote:
>>>>
>>>>> Sure, you let me know a time. I'm working on getting Catch up to date
>>>>> as well. BTW, Arquillian 1.0.0.Final will be out tomorrow, not sure about
>>>>> container support though.
>>>>>
>>>>>
>>>>> On Tue, Jul 5, 2011 at 20:22, Ken Finnigan < <ken at kenfinnigan.me><ken at kenfinnigan.me>
>>>>> ken at kenfinnigan.me> wrote:
>>>>>
>>>>>> Jason,
>>>>>>
>>>>>> If you have some time tomorrow it would be appreciated if you could
>>>>>> take a look at the new testsuite setup on i18n. Here's the branch: git://<http://github.com/kenfinnigan/international.git><http://github.com/kenfinnigan/international.git>
>>>>>> github.com/kenfinnigan/international.git
>>>>>>
>>>>>> I thought I was making progress but now I seem to have managed to move
>>>>>> backwards! For some reason I keep getting a NoClassDef errors on aether
>>>>>> classes. It appears that the classes are brought in correctly from the
>>>>>> arquillian junit container (from shrinkwrap beta 3), but then the jboss as
>>>>>> managed container brings in an older version of shrinkwrap that doesn't
>>>>>> include aether.
>>>>>>
>>>>>> I'm sure it's a simple fix, as I've mirrored it off confbuzz, servlet
>>>>>> and rest, as well as jbossas, that all run as7 arquillian tests, but can't
>>>>>> see the wood for the trees tonight. Will be looking at it again tomorrow
>>>>>> evening, but if you can spot an easy fix that would be great!
>>>>>>
>>>>>> Thanks
>>>>>> Ken
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 5, 2011 at 1:39 PM, Jason Porter < <http://lightguard.jp><http://lightguard.jp>
>>>>>> lightguard.jp@ <http://gmail.com> <http://gmail.com>gmail.com> wrote:
>>>>>>
>>>>>>> Okay, great. Let me or Dan know if you need some help.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 5, 2011 at 11:37, Ken Finnigan < <ken at kenfinnigan.me><ken at kenfinnigan.me>
>>>>>>> ken at kenfinnigan.me> wrote:
>>>>>>>
>>>>>>>> Pretty good.
>>>>>>>>
>>>>>>>> Have the basic structure for the module in terms of what needs to go
>>>>>>>> where.
>>>>>>>>
>>>>>>>> Currently going through and getting the existing i18n tests working
>>>>>>>> in AS7, which is proving more of a challenge than I expected!
>>>>>>>>
>>>>>>>> Of all the tests that pass in weld-ee-embedded, about a third
>>>>>>>> actually pass in AS7! Most of it, I think, is down to differing classpaths,
>>>>>>>> but should be in a position to push the feature branch to my fork of i18n in
>>>>>>>> a couple of days.
>>>>>>>>
>>>>>>>> Once I've pushed it to my fork I was going to send an email to
>>>>>>>> everyone on seam-dev to get their thoughts on the layout/setup for testing.
>>>>>>>>
>>>>>>>> btw, you don't need to worry about cc'ing my sorstech email in the
>>>>>>>> future as I don't use that much anymore.
>>>>>>>>
>>>>>>>> Ken
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Jul 5, 2011 at 1:20 PM, Jason Porter <<http://lightguard.jp><http://lightguard.jp>
>>>>>>>> lightguard.jp@ <http://gmail.com> <http://gmail.com>gmail.com>wrote:
>>>>>>>>
>>>>>>>>> How goes things with i18n and the new Arquillian?
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Jason Porter
>>>>>>>>> <http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.com>
>>>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>>>> <http://twitter.com/lightguardjp><http://twitter.com/lightguardjp>
>>>>>>>>> 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: <http://keyserver.net><http://keyserver.net>
>>>>>>>>> keyserver.net, <http://pgp.mit.edu> <http://pgp.mit.edu>
>>>>>>>>> pgp.mit.edu
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jason Porter
>>>>>>> <http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.com>
>>>>>>> http://lightguard-jp.blogspot.com
>>>>>>> <http://twitter.com/lightguardjp> <http://twitter.com/lightguardjp>
>>>>>>> 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: <http://keyserver.net> <http://keyserver.net>
>>>>>>> keyserver.net, <http://pgp.mit.edu> <http://pgp.mit.edu>pgp.mit.edu
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jason Porter
>>>>> <http://lightguard-jp.blogspot.com><http://lightguard-jp.blogspot.com>
>>>>> http://lightguard-jp.blogspot.com
>>>>> <http://twitter.com/lightguardjp> <http://twitter.com/lightguardjp>
>>>>> 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: <http://keyserver.net> <http://keyserver.net>
>>>>> keyserver.net, <http://pgp.mit.edu> <http://pgp.mit.edu>pgp.mit.edu
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Jason Porter
>> <http://lightguard-jp.blogspot.com>http://lightguard-jp.blogspot.com
>> <http://twitter.com/lightguardjp>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: <http://keyserver.net>keyserver.net,
>> <http://pgp.mit.edu>pgp.mit.edu
>>
>
>
> _______________________________________________
> 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/20110710/6d4f82e6/attachment-0001.html
More information about the seam-dev
mailing list