blob: 4012f41a9e8e4db8136ff707bf95a996c369ec2b [file] [log] [blame]
------
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.
Myfaces Test Framework Project
Modern application development processes have embraced the idea of
<<unit testing>> as an integral step in creating high quality
software. In the Java world, a popular framework for building and
executing such unit tests is the {{{http://junit.org}JUnit}}
framework. It is straightforward for an application developer to
create a corresponding <<test case>> class for each class in the
application itself, and ensure that the tests contained in the test case
get executed as part of the normal application build process.
One of the advantages of unit testing is that a test case should focus
<<only>> on the methods of the class under test, in isolation from
related application classes, or APIs provided by any container that the
class under test might be installed into at runtime. But, how do you
test an application class that has dependencies on such APIs (such as
depending on the Servlet API to provide an <<<HttpServletRequest>>>
object representing an incoming HTTP request)?
A popular answer to this dilemma is to utilize a library of
<<mock objects>> -- classes that implement and emulate the container
APIs, but still run in the isolated environment of a JUnit test case.
Myfaces provides mock object implementations for its own features, as
well as features of the underlying container (Servlet
and JavaServer Faces) environment. In addition, convenient base classes
are provided to make it very easy to build your own test cases utilizing
these mock objects. This library is used to create unit tests for Myfaces
components itself, but it is primarily focused on making it easy to
build unit tests for application classes such as
<<<ViewController>>>s.
Provided Services
The Myfaces Test Framework provides mock object libraries, plus base
classes for creating your own JUnit <<<TestCase>>>s.
Mock objects are provided in package <<<org.apache.myfaces.test.mock>>>
for the following container APIs:
* JavaServer Faces
* Servlet
These mock object classes implement the majority of the functionality
defined by the container API Javadocs (although some methods currently
throw <<<UnsupportedOperationException>>>). In addition, many
of these classes support public methods, outside of the defined API,
for configuring the object in a test environment. For example,
<<<MockServletContext>>> includes <<<addInitParameter()>>>
and <<<setDocumentRoot()>>> methods, to add context initialization
parameters to the set returned via <<<getInitParameter()>>> and
<<<getInitParameterNames()>>>, and to establish the base directory
for resolving servlet context resources, respectively.
The <<<org.apache.myfaces.test.base>>> package contains abstract
base classes that wire together instances of the various container API
mock objects, in a manner similar to the way they would become available
at runtime. The following base classes are available:
* <<<org.apache.myfaces.test.base.AbstractJsfTestCase>>> - Base class
for unit tests that require Servlet and JavaServer Faces objects to
be available in a junit 3 style.
* <<<org.apache.myfaces.test.base.AbstractViewControllerTestCase>>> - Extension of
<<<AbstractJsfTestCase>>> that also provides convenient
utility methods needed to test common scenarios in unit tests for
<<<ViewController>>> implementation classes in a junit 3 style.
* <<<org.apache.myfaces.test.base.junit4.AbstractJsfTestCase>>> - Base class
for unit tests that require Servlet and JavaServer Faces objects to
be available in a junit 4 style.
* <<<org.apache.myfaces.test.base.AbstractViewControllerTestCase>>> - Extension of
<<<AbstractJsfTestCase>>> that also provides convenient
utility methods needed to test common scenarios in unit tests for
<<<ViewController>>> implementation classes in a junit 4 style.
* <<<org.apache.myfaces.test.base.junit4.AbstractJsfConfigurableMockTestCase>>> - Base class
for unit tests that require Servlet and JavaServer Faces objects to
be available in a junit 4 style. It to allows override mock objects to use the
"real" ones in cases where it is required to test specific parts of myfaces,
or create test cases that requires parts of a jsf implementation to work
(see on myfaces-impl 2.0.x base class org.apache.myfaces.view.facelets.FaceletTestCase)
If you use one of these base classes, the <<<setUp()>>> method
found there will initialize a set of <<<protected>>> instance
variables for the container-managed objects you might need to access.
The set of initialized variables includes (variable name and type):
* <<<application>>> (<<<MockApplication>>>)
* <<<config>>> (<<<MockServletConfig>>>)
* <<<externalContext>>> (<<<MockExternalContext>>>)
* <<<facesContext>>> (<<<MockFacesContext>>>)
* <<<lifecycle>>> (<<<MockLifecycle>>>)
* <<<request>>> (<<<MockHttpServletRequest>>>)
* <<<response>>> (<<<MockHttpServletResonse>>>)
* <<<servletContext>>> (<<<MockServletContext>>>)
* <<<session>>> (<<<MockHttpSession>>>)