...
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 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.
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:
...
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 org.apache.myfaces.test.base.AbstractViewControllerTestCase
- Extension of AbstractJsfTestCase
that also provides convenientViewController
implementation classes in a junit 3 style.org.apache.myfaces.test.base.junit4.AbstractJsfTestCase
- Base class org.apache.myfaces.test.base.AbstractViewControllerTestCase
- Extension of AbstractJsfTestCase
that also provides convenient ViewController
implementation classes in a junit 4 style.org.apache.myfaces.test.base.junit4.AbstractJsfConfigurableMockTestCase
- Base class 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):
...