Wiki page how functional tests could be run is located at [1], a part of
FAQs. The code is in the repository.
Karel
[1]
This is great that you guys are getting this effort started early.
I may be stating the obvious here, but make sure you also have a wiki
page or a section in the documentation early on about how to run the
tests (perhaps the documentation is that there is no config required).
That way, the team gets used to using these tests from day #1. I know
that it would help me a lot if I could use the selenium tests locally
to make sure I'm not breaking anything. Breaking builds seems to be a
subconscious form of relaxation for me.
-Dan
On Wed, Dec 9, 2009 at 1:29 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
On Wed, 2009-12-09 at 12:22 +0000, Pete Muir wrote:
> Hi Karel,
>
> I like the plan in general :-)
>
> On 8 Dec 2009, at 16:55, Karel Piwko wrote:
>
> > Hi all,
> >
> > there is QA proposal of integrating functional tests into
Maven
> > lifecycle for building weld/seam-examples:
> >
> > 1/ Add an profile "ftest" into pom.xml of
weld-examples-parent.
> > This profile contains all the necessary build executions
> > (starting container/deploying/running Selenium/
> > collecting results/undeploying/stopping container),
> > so this can be shared by examples.
>
> Ok, sounds good.
>
> > 2/ In a example, add the same "ftest" profile with
dependency on
> > ftest-example artifact. This dependency is interval
based,
>
> What does this mean?
It means that each example "foo" contains ftest <profile>
which add test
scoped dependency ftest-foo. So basically each ftest artifact
for an
example is independent of all the other tests. The artifact is
fetched
from Maven repository during integration-test phase if ftest
profile is
activated. The interval dependency allows as to cover more of
example
without need changing dependency in after each ftest is
released.
Did I clarify that?
>
> > so
> > there is no need to release the example when its ftest
changes.
> > Then add the testsuite for container into src/test/
directory of
> > example.
>
> Sounds good.
>
> > 3/ Running maven with ftest profile will execute
functional tests during
> > integration-test phase
>
> Ok.
>
> >
> > So, all ftests are maven artifacts, downloaded from
repository when
> > needed, normal build is untouched. We implemented this
proposal for
> > Weld jsf/numberguess example and things are working fine.
> >
> > There are currently two problems :
> > a/ Although weld-examples-parent contains ftest profile,
this cannot be
> > used to recursively test all modules, because there is
no way how
> > selectively activate this profile only for modules where
this
> > is applicable (will be working in Maven 3). This
shouldn't be the
> > problem, because in the end examples will be mainly
parts of
> > weld|seam-modules, so this couldn't be used as well.
>
> Ondrej explained that the issue here is that you are getting
the plugin config activated in children with no tests. Have
you tried putting the config in <pluginManagement> and only
activating the plugin in the relevant children?
>
Actually, it was that plugins were activated in parent element
which
contained the profile. But thanks for the tip, putting all the
configuration into <pluginManagement> tags works fine, and
requires only
adding about 15 lines into each examples's ftest profile,
which is not
that bad.
> > b/ User is required to pass reference to ftest.properties
file with
> > -Dftest.properties, but this file is not a part of
example
> > distribution. We can add this file or its skeleton to
each example,
> > but it doesn't seem right.
>
> What does this file do?
>
> In Seam 2 we use this file to capture various configuration
options
> needed for the functional testsuite, namely:
>
> - selenium configuration (port, host, browser, domain, ...)
> - container configuration (which container to use,
jboss.home, deploy
> timeout, jvm arguments, jmx credentials, ...)
> - seam-gen setup (workspace, driver.jar, ...)
>
> The fact is that a lot of these items has never been touched
(all the
> selenium conf except for browser selection, jboss
credentials,
> etc...,
> so these should have default (overridable) values without an
explicit
> entry in ftest.properties)
>
Ok, I moved configuration from file into parent's plugin
management
<properties> block. Works fine.
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen