[weld-dev] [seam-dev] Weld functional tests

Karel Piwko kpiwko at redhat.com
Thu Dec 17 10:10:41 EST 2009


Wiki page how functional tests could be run is located at [1], a part of
FAQs. The code is in the repository.

Karel

[1]
http://www.seamframework.org/Documentation/HowDoIRunFunctionalTestsOnWeldExamples

On Wed, 2009-12-09 at 16:54 -0500, Dan Allen wrote:
> 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 at 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 at 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



More information about the weld-dev mailing list