Arquillian Testsuite structure for Modules
by Ken Finnigan
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-...
- 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.mdout...
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
13 years, 5 months
Introducing Hanneli Tavante
by Jason Porter
Everyone, I'd like to introduce you all to Hanneli Tavante. She's been
following us on twitter for awhile. She's an avid Seam 3 user and advocate
down in Brazil (yep, we keep getting more people interested down there :) ).
She's also expressed some interest in helping us with some documentation and
examples / tutorials! so when you get some documentation pull requests
you'll know who they're from! Thank you Hanneli for helping us out!
--
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
13 years, 6 months
3 weeks until Seam 3.1 Beta1
by Shane Bryzak
Just a heads up to everyone that we only have 3 weeks remaining until
the beta 1 release for Seam 3.1. It would be appreciated if all module
leads could reply to this with a status update for your module, and
whether you foresee any issues with delivering a beta for your module
within this timeframe.
I'd also like to remind everyone that we are getting rid of the shaded
(combined) jars, so if you need assistance in doing this for your module
please let me know and I can help out.
Shane
13 years, 6 months
s:viewAction test failure
by Brian Leathem
Hello all,
I've written some JSFUnit/Arquillian tests for the viewAction, currently
targeting JBoss AS6 as a baseline.
There are two tests (available in faces/fetaure/jsfunit_arquillian branch):
// testing the viewAction loading data into a property
@Test
@InitialPage("/load_data.xhtml")
public void checkDataLoad(JSFServerSession server,
JSFClientSession client) throws IOException {
Assert.assertEquals("/load_data.xhtml", server.getCurrentViewID());
Assert.assertTrue(client.getPageAsText().contains("Data Loaded"));
}
// testing viewAction navigation
@Test
@InitialPage("/goto_result.xhtml")
public void checkNavigation(JSFServerSession server,
JSFClientSession client) throws IOException {
Assert.assertEquals("/result.xhtml", server.getCurrentViewID());
Assert.assertTrue(client.getPageAsText().contains("Result page"));
}
The first test works, but the second one fails with the server.log
stacktrace:
https://gist.github.com/1078369
I verified this failure with a manually created example app (available
in faces/examples on the develop branch).
This is consistent with the behavior reported in the forums:
s:viewAction navigation is broken. It seems to be a weld issue,
perhaps:
https://issues.jboss.org/browse/WELD-878
although the error message seems different.
This is an increasingly important at the moment, as the viewAction is
being considered for inclusion in JSF 2.2.
Any thoughts on how to proceed? It's hard to share these tests at the
moment, as they are based on a JSFUnit snapshot that one must compile
onself. Another JSFUnit beta realease would help out here. Also, It
would probably help to have these tests target other containers, such as
AS7, Glassfish 3.x - although I think JSFUnit/Arquillian has some
compatibility issues here at the moment.
Cheers,
Brian Leathem
13 years, 6 months
Re: [seam-dev] Arquillian update
by Jason Porter
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
13 years, 6 months
Seam JCR Alpha-2
by George Gastaldi
Hello,
I´ve spoken with John and we agreed that the current codebase of Seam JCR is
stable enough for an Alpha-2 release.
Shane, can you add that release procedure to your to-do list and let us know
when is finished ?
Thanks,
George Gastaldi
13 years, 6 months
Seam Security security.drl
by Marek Schmidt
Hi all,
looking at https://issues.jboss.org/browse/SEAMSECURITY-81, I am not
sure, what is the intended location of the security.drl file?
The examples have it in WEB-INF/security.drl, but that doesn't work
except on AS6.
The SecurityRuleProducer injects the file using:
> @Inject
> @org.jboss.seam.solder.resourceLoader.Resource("security.drl")
> InputStream securityRules;
So I am not sure which of these are true statements:
1. Seam Security examples are wrong, the file should be moved to servlet
context root
2. Seam Security impl is wrong, it should @Inject it from
"WEB-INF/security.drl"
3. Seam Solder on AS7/Glassfish is wrong, it should pick up the file
WEB-INF/security.drl using just the @Resource("security.drl") on these
platforms
4. Seam Solder on AS6 is wrong, it should not pick up the file
WEB-INF/security.drl using just the @Resource("security.drl") on AS6.
Cheers,
Marek Schmidt
13 years, 6 months
Docbook help
by Jason Porter
It's a large download (100MB for the free version) but
http://www.syntext.com/downloads/serna/ really seems to help. You can get
WYSIWG editing and validation. At least better than trying to know all the
docbook tags :) Also, anyone that needs some help, please come to #pressgang
on freenode, the documentation team for JBoss hang out there and can help.
They're in Brisbane though, so time zones may not be great for some of us.
--
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
13 years, 6 months
