Author: Plone Foundation



.. contents:: Table of contents

``plone.testing`` provides tools for writing unit and integration tests in a
Zope and Plone environment. It is not tied to Plone, and it does not depend on
Zope 2 (although it has some optional Zope 2-only features).

``plone.testing`` builds on `zope.testing`_, in particular its layers concept.
This package also aims to promote some "good practice" for writing tests of
various types.

    **Note:** If you are working with Plone, there is a complementary package
    ``_, which builds on ``plone.testing`` to provide
    additional layers useful for testing Plone add-ons.

If you are new to automated testing and test driven development, you should
spend some time learning about those concepts. Some useful references include:

* `The Wikipedia article on unit testing <>`_
* `The Dive Into Python chapter on testing <>`_

Bear in mind that different Python frameworks have slightly different takes on
how to approach testing. Therefore, you may find examples that are different
to those shown below. The core concepts should be consistent, however.


``plone.testing`` 4.x has only been tested with Python 2.6. If you're using the
optional Zope 2 layers, you must use Zope version 2.12 or later.
Look at ``plone.testing`` 3.x for Zope 2.10 support.


In this documentation, we will use a number of testing-related terms. The
following definitions apply:

Unit test
    An automated test (i.e. one written in code) that tests a single unit
    (normally a function) in isolation. A unit test attempts to prove that the
    given function works as expected and gives the correct output given a
    particular input. It is common to have a number of unit tests for a single
    function, testing different inputs, including boundary cases and errors.
    Unit tests are typically quick to write and run.
Integration test
    An automated test that tests how a number of units interact. In a Zope
    context, this often pertains to how a particular object or view interacts
    with the Zope framework, the ZODB persistence engine, and so on.
    Integration tests usually require some setup and can be slower to run than
    unit tests. It is common to have fewer integration tests than unit test.
Functional test
    An automated test that tests a feature in an "end-to-end" fashion. In a
    Zope context, that normally means that it invokes an action in the same
    way that a user would, i.e. through a web request. Functional tests are
    normally slower to run than either unit or integration tests, and can be
    significantly slower to run. It is therefore common to have only a few
    functional tests for each major feature, relying on unit and integration
    tests for the bulk of testing.
Black box testing
    Testing which only considers the system's defined inputs and outputs. For
    example, a functional test is normally a black box test that provides
    inputs only through the defined interface (e.g. URLs published in a web
    application), and makes assertions only on end outputs (e.g. the response
    returned for requests to those URLs).
White box testing
    Testing which examines the internal state of a system to make assertions.
    Authors of unit and integration tests normally have significant knowledge
    of the implementation of the code under test, and can examine such things
    as data in a database or changes to the system's environment to determine
    if the test succeeded or failed.
    A check that determines whether a test succeeds or fails. For example, if
    a unit test for the function ``foo()`` expects it to return the value 1,
    an assertion could be written to verify this fact. A test is said to
    *fail* if any of its assertions fail. A test always contains one or more
Test case
    A single unit, integration or functional test. Often shortened to just
    *test*. A tes