myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "Running_the_Test_Harness" by ScottOBryan
Date Fri, 06 Nov 2009 23:12:42 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The "Running_the_Test_Harness" page has been changed by ScottOBryan.
The comment on this change is: Adding some documentation for test harness.
http://wiki.apache.org/myfaces/Running_the_Test_Harness?action=diff&rev1=1&rev2=2

--------------------------------------------------

- Describe Running_the_Test_Harness here.
+ == Myfaces Portlet Bridge Test Harness ==
  
+ <<Anchor(TestValue)>>
+ === What is the Portlet Bridge Test Harness and why is it useful to me? ===
+ [[#TestValue|permlink]]
+ The Myfaces Portlet Bridge Test Harness is a system to test a portlet bridge implementation
against the specification.  While it is still under development, the project has two main
goals:
+ 
+ 1. Be able to quickly run a MyFaces Portlet Bridge implementation against a built-in pluto/jetty
environment in order to test spec compliance as a prelude to final TCK testing and approval.
 This includes verifications against MyFaces and Mojarra.  The testing framework should also
allow other bridge implementations to be tested in this environment.  If the bridge implementation
is available in a maven repository, it can be substituted in for the MyFaces Portlet Bridge
simply by setting a few command line arguments.
+ 
+ 2. Be able to test the generate a test war file which may be deployed into other portal
environments in order to test portlet bridge implementation on other Portals.  Once this war
is deployed, the test harness should be able to be run against these external servers to ensure
compliance.
+ 
+ <<Anchor(TestTCK>>
+ === How does this relate to the TCK ===
+ [[#TestTCK|permlink]]
+ The Portlet Bridge Test harness will ease specification compliance testing of JSF Portlet
Bridges, but it is not meant to replace the TCK.  According to the JSP, the company responsible
for the project must produce a well versioned and complete TCK to ensure compliance.  In this
case, that would be Oracle.  This project will be the basis for the TCK compliance testing
released from Oracle.  It is intended that the tests will be developed here and, at some point,
Oracle will repackage the code into an official TCK.  In order to claim spec compliance, all
Portlet Bridge implementation will need to pass the official TCK, but using this test harness
until that time should give you a fairly good indicator of where your bridge implementation
may fall short.
+ 
+ === How does it work ===
+ 
+ The current test suite can be pulled down from http://svn.apache.org/repos/asf/myfaces/portlet-bridge/testsuite/trunk.
 All you need to do is download the source tree and type:
+ 
+ mvn install
+ 
+ This will compile and run the test suite against the latest Portlet Bridge. (Currently this
will try to use the 1.0.0-SNAPSHOT, but this will become the latest released version soon).
 There are a lot of option for the build, so I will try to specify some of those below.
+ 
+ ==== Changing JSF Implementations ====
+ By default the test suite will compile and run the tests against Mojarra.  Although this
is an Apache project, Mojarra is the default because of the TCK compliance issues.  It is
very simple to change the tests to run against myfaces however, by simply adding:
+ 
+ -Djsf=myfaces
+ 
+ Also, by default the test harness tests against the minimum JSF versions avaialble in the
specification.  For mojarra, it will test against 1.2_03 and for myfaces it will test against
1.2.2.  To change the version of faces being used to run the tests, you simply need to add
the following:
+ 
+ -Djsf.version=1.2.7
+ 
+ Therefore, running the tests against Myfaces 1.2.7 would be:
+ 
+ mvn -Djsf=myfaces -Djsf.version=1.2.7 install
+ 
+ ==== Substituting Bridge Implementation ====
+ 
+ One of the main goals of the Test Framework is to be able to quickly and easily test other
bridge implementations.  There are a lot of configuration options for doing this provided
your bridge is available in the maven repository.  If it is not, then you will need to mock
up the test war file yourself and deploy the app to an external portal server.  Eventually
the Test Harness should be able to support running against servers in this environment.  For
now, lets start with the simplest case and work our way from there:
+ 
+ Currently the framework is set up to test against the Portlet Bridge 1.0.0-SNAPSHOT.  This
means that for everything to work, you would have had to have installed the latest trunk.
 Let's say, however, that you want to run the test harness against the latest released version
of the bridge.  You could specify this by setting the following:
+ 
+ mvn -Dportlet-bridge.version=1.0.0-beta-2 install
+ 
+ This will download the 1.0.0-beta-2 version of the MyFaces Portlet Bridge and run the verification
tests against it.  Expect quite a few failures in the beta code, the trunk passes many more
of the verification tests.. ;)
+ 
+ Now let us say that we want to run the Testing framewok against the JBoss Portlet Bridge,
you could specify the artifact and the group id's as follows:
+ 
+ mvn -Dportlet-bridge.version=1.0.0-CR3 -Dportlet-bridge.groupId=org.jboss.portletbridge
-Dportlet-bridge.api.artifactId=portletbridge-api -Dportlet-bridge.impl.artifactId=portletbridge-impl
-Dmaven.repo.remote=http://repository.jboss.org/maven2/ install
+ 
+ ...more to come...
+ 
+ || property name || default value || allowed values || description ||
+ || jsf || mojarra* || mojarra, myfaces || allows you to specify the faces implementation
to be used for testing.  If used in conjunction with the -Dportlet.tck.make-war=true property
then specifying this flag will ''include'' the JSF implementation specified in the war file's
WEB-INF/lib ||
+ || jsf.version || 1.2_03 (for mojarra) or 1.2.2 (for myfaces) || || allows you to specify
a version number of the Faces implementation to test against. ||
+ || portlet-bridge.groupId || org.apache.myfaces.portlet-bridge || || allows you to specify
a groupId for the bridge implementation which should be tested against.  It is assumed that
this is available to maven.  For more fine grained control (for instance if you want to use
the R.I's api but your own bridge implementation), you can declare a groupId for the portlet-bridge.api.groupId
and portlet-bridge.impl.groupId separately.  By default, however, both of those properties
contain the value of this property. ||
+ || portlet-bridge.version || 1.0.0-SNAPSHOT || || allows you to specify a version for the
bridge implementation which should be tested against.  It is assumed that this is available
to maven.  For more fine grained control (for instance if you want to use the R.I's api but
your own bridge implementation), you can declare a version for the portlet-bridge.api.version
and portlet-bridge.impl.version separately.  By default, however, both of those properties
contain the value of this property. ||
+ || portlet-bridge.api.groupId || ${portlet-bridge.groupId} || || see portlet-bridge.groupId
||
+ || portlet-bridge.api.artifactId || portlet-bridge-api || || allows you to specify a artifactId
for the bridge api which should be tested against.  It is assumed that this is available to
maven. ||
+ || portlet-bridge.api.version || ${portlet-bridge.version} || || see portlet-bridge.version
||
+ || portlet-bridge.impl.groupId || ${portlet-bridge.groupId} || || see portlet-bridge.groupId
||
+ || portlet-bridge.impl.artifactId || portlet-bridge-impl || || allows you to specify a artifactId
for the bridge implementation which should be tested against.  It is assumed that this is
available to maven. ||
+ || portlet-bridge.impl.version || ${portlet-bridge.version} || || see portlet-bridge.version
||
+ 

Mime
View raw message