------ | |
Myfaces Test Framework | |
------ | |
~~ Licensed to the Apache Software Foundation (ASF) under one | |
~~ or more contributor license agreements. See the NOTICE file | |
~~ distributed with this work for additional information | |
~~ regarding copyright ownership. The ASF licenses this file | |
~~ to you under the Apache License, Version 2.0 (the | |
~~ "License"); you may not use this file except in compliance | |
~~ with the License. You may obtain a copy of the License at | |
~~ | |
~~ http://www.apache.org/licenses/LICENSE-2.0 | |
~~ | |
~~ Unless required by applicable law or agreed to in writing, | |
~~ software distributed under the License is distributed on an | |
~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY | |
~~ KIND, either express or implied. See the License for the | |
~~ specific language governing permissions and limitations | |
~~ under the License. | |
Using The Test Framework | |
The most common scenario for using the Test Framework is to construct | |
test cases for <<<ViewController>>> implementation classes. | |
Because the runtime environment of a <<<ViewController>>> is | |
quite constrained, it is easy to construct isolated unit tests that | |
exercise the methods exposed by a <<<ViewController>>> class. | |
[[1]] Create a new Java class <<<SelectTestCase>>>, in a package | |
directory (typically under <<<src/test>>> in your project) | |
that is the same as the package directory for the class you will be | |
testing. This allows your test case to access package private and | |
protected variables and methods in the class being tested. | |
[[2]] Make sure that the package declaration matches that of the class to | |
be tested (in this case, <<<org.apache.myfaces.usecases.locale>>>. | |
Declare your class to extend <<<AbstractViewControllerTestCase>>> | |
(or, if you are not testing a <<<ViewController>>> implementation, | |
extend <<<AbstractJsfTestCase>>>): | |
+-------------------------------+ | |
public class SelectTestCase extends AbstractViewControllerTestCase { | |
... | |
} | |
+-------------------------------+ | |
[[3]] Create a constructor that takes a <<<String>>> parameter, and | |
passes it to the superclass constructor: | |
+-------------------------------+ | |
public SelectTestCase(String name) { | |
super(name); | |
} | |
+-------------------------------+ | |
[[4]] Create a <<<setUp()>>> method and <be sure> | |
to call <<<super.setUp()>>> at the beginning. This method | |
will be called by JUnit immediately before it executes each | |
test method. | |
+-------------------------------+ | |
public void setUp() { | |
super.setUp(); | |
// Customization will go here | |
} | |
+-------------------------------+ | |
[[5]] After the call to the superclass <<<setUp()>>> method, | |
perform any other initialization required to execute the tests | |
in this test case. In our example case, a configuration method | |
on the <<<MockApplication>>> instance will be used to | |
define the default and supported <<<Locale>>>s for this | |
set of tests. This corresponds to what would happen at runtime, | |
when the JavaServer Faces initialization process used the contents | |
of the <<</WEB-INF/faces-config.xml>>> resource to initialize | |
these values. In addition, we will create a new instance of the | |
<<<Select>>> class to be tested. It is important to create | |
a new instance for each test, to ensure that execution of one test | |
does not get influenced by the leftover property settings from a | |
previous test. | |
+-------------------------------+ | |
public void setUp() { | |
super.setUp(); | |
// Configure the supported locales for this application | |
List list = new ArrayList(); | |
list.add(new Locale("en")); | |
list.add(new Locale("fr")); | |
list.add(new Locale("de")); | |
list.add(new Locale("es")); | |
application.setSupportedLocales(list); | |
// Construct a new ViewController instance | |
vc = new Select(); | |
} | |
+-------------------------------+ | |
[[6]] Create a <<<tearDown()>>> method that cleans up any custom | |
variables you allocated in your <<<setUp()>>> method, and | |
then calls the <<<super.tearDown()>>> method. This will be | |
called by JUnit after each test is executed. | |
+-------------------------------+ | |
public void tearDown() { | |
vc = null; | |
super.tearDown(); | |
} | |
+-------------------------------+ | |
[[7]] Declare the custom instance variable(s) that you are setting up | |
in your <<<setUp()>>> method. In this case, we create an | |
instance of the <<<ViewController>>> class to be tested. | |
A new instance will be created (via a call from JUnit to the | |
<<<setUp()>>> method) before each test method is executed. | |
+-------------------------------+ | |
// The instance to be tested | |
Select vc = null; | |
+-------------------------------+ | |
[[8]] Create one or more individual test methods (which must be | |
<<<public>>>, return <<<void>>>, take no arguments, | |
and have a method name of the form <<<testXXXX>>>. For | |
advice on how to construct such methods, consult the | |
{{{http://junit.org/}JUnit Web Site}}, or any of the | |
large number of resources on the web describing how to use JUnit | |
to build unit tests. The following example tests what happens | |
when the <<<select()>>> method (which is executed when | |
the <<Go>> button is pressed), but the value entered is not | |
one of the valid options. <NOTE> that the test | |
method must emulate the runtime calls to the <<<ViewController>>> | |
event methods, because there is no actual runtime container | |
available to perform these tasks automatically: | |
+-------------------------------+ | |
// Test behavior of select() with an invalid value | |
public void testSelectInvalid() { | |
Locale locale = new Locale("en"); | |
facesContext.getViewRoot().setLocale(locale); | |
vc.init(); | |
vc.preprocess(); | |
vc.setLocale("it"); | |
String result = vc.select(); | |
assertEquals(Select.FAILURE, result); | |
checkMessageCount(1); | |
assertEquals(locale, facesContext.getViewRoot().getLocale()); | |
} | |
+-------------------------------+ | |
The test case sets the <<<locale>>> property (which is | |
bound to a dropdown component at runtime, but we are simulating | |
the behavior of Update Model Values here) to an invalid value, | |
then calls the <<<select()>>> method. The test then | |
verifies that the logical outcome returned matches that which | |
is expected (<<<Select.FAILURE>>>), that there was an error | |
message queued to be displayed, and that the <<<locale>>> | |
for the current view was <NOT> actually changed. | |
[[9]] Finally, integrate the execution of this test case into your | |
build script. Many IDEs will take care of this for you; however, | |
if you are creating an Ant build script by hand, you might find | |
the <<<test>>> target from the Myfaces Use Cases example | |
a useful starting point. It locates <<all>> the test cases | |
related to the entire application, and executes them: | |
+-------------------------------+ | |
<target name="test" depends="test.compile" | |
description="Execute unit tests"> | |
<mkdir dir="${build.home}/test-results"/> | |
<echo message="Running unit tests ..."/> | |
<junit printSummary="no" fork="yes" | |
haltonfailure="yes" haltonerror="yes"> | |
<classpath refid="test.classpath"/> | |
<formatter type="plain" | |
usefile="false"/> | |
<formatter type="xml" | |
usefile="true"/> | |
<batchtest todir="${build.home}/test-results"> | |
<fileset dir="${build.home}/test-classes" | |
includes="org/apache/myfaces/usecases/*/*TestCase.class"/> | |
</batchtest> | |
</junit> | |
</target> | |
+-------------------------------+ |