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(a)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 <lightguard.jp(a)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(a)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>
> lightguard.jp@ <
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(a)kenfinnigan.me>
>> ken(a)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>
>>>
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>
>>> lightguard.jp@ <
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(a)kenfinnigan.me>
>>>> ken(a)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>
>>>>> lightguard.jp@ <
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://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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>
--
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