FunctionalTesting

Functional Testing Readme

The functional testing support of ZopeTestCase was inspired by Marius Gedminas' work for Zope 3.

Deriving from the Functional mix-in (and an xTestCase) adds a publish method to your test case class. Tests can call self.publish(path, basic=None, env=None, extra=None, request_method="GET" stdin=None), passing a path and, optionally, basic-auth info and form data. The path may contain a query string.

publish returns an enhanced Response object, that can be queried for status, response body, headers, etc.

publish invokes the ZPublisher machinery just as if the request had come in through ZServer. This allows for high-level testing of things like argument marshalling, form validation, and traversal.

Note that the tests have full access to the ZODB. This means you can easily prepare a fixture for publish and/or check the impact of a publication on the database. This represents a major advantage over purely URL-based test environments!

Please see the testFunctional.py example test for more.

While the modules are called functional.py in both Zope 3 and ZopeTestCase, it is current wisdom that such tests are not truly "functional tests", but rather "integration tests".

True functional tests, in their most-helpful guise as "acceptance tests", must be able to test the end-user experience. For web applications this means: browser simulation.

Plone 2 comes with an ftests package combining the functional testing support of ZopeTestCase with the "mechanize" browser simulator library: http://wwwsearch.sourceforge.net/mechanize/ (For some version of 2, currently only available from the Plone SVN trunk.)

Read the Source

Amen. Read functional.py and sandbox.py if you want to know what's going on behind the scenes.