Myfaces Portlet Bridge Test Harness
What is the Portlet Bridge Test Harness and why is it useful to me?
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
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 |