[Zope3-checkins] CVS: Zope3/doc - UNITTEST.txt:1.4
Guido van Rossum
guido@python.org
Fri, 9 Aug 2002 12:51:10 -0400
Update of /cvs-repository/Zope3/doc
In directory cvs.zope.org:/tmp/cvs-serv23772
Modified Files:
UNITTEST.txt
Log Message:
Actualized for Zope 3. Added up-to-date instructions for running unit
tests at the top.
=== Zope3/doc/UNITTEST.txt 1.3 => 1.4 ===
--- Zope3/doc/UNITTEST.txt:1.3 Fri Apr 12 11:53:36 2002
+++ Zope3/doc/UNITTEST.txt Fri Aug 9 12:51:10 2002
@@ -1,4 +1,12 @@
-Zope Unit Testing
+Zope 3 Unit Testing
+
+ How to run Zope 3 unit tests
+
+ In the toplevel directory, run "python test.py". This runs all unit
+ tests silently (unless errors occur). It is possible to run the
+ tests more verbosely or to be more selective about which tests to
+ run. There are also other options. For information about all this,
+ run "python test.py -h" which prints an extensive usage message.
Zope Testing
@@ -157,9 +165,8 @@
any more of this. :-) The rules for writing tests for Zope core
code are simple:
- - The testing code should make use of PyUnit
- (/lib/python/unittest.py). Instructions for using PyUnit are
- available at http://pyunit.sourceforge.net.
+ - The testing code should make use of the standard Python unittest
+ module. See the Python docs for usage information.
- Tests must be placed in a "tests" subdirectory of the package or
directory in which the core code you're testing lives.
@@ -173,11 +180,9 @@
Writing Unit Tests For Applications Based On Zope
- Zope uses the PyUnit unit testing framework, the documentation for
- which is available at http://pyunit.sourceforge.net. The
- lib/python/unittest.py module is the framework. You should
- establish your own conventions for naming and placement of test
- modules.
+ Zope uses the standard Python unittest module. See the Python docs
+ for usage information. You should establish your own conventions
+ for naming and placement of test modules.
Writing unit tests against applications based on Zope can be
difficult. Zope is a collection of related modules, some with
@@ -210,78 +215,10 @@
you're heavy in to unit testing, as it really speeds things up.
It's not strictly required, however.
- Making Zope itself into a test fixture is straightforward. Your
- test code must:
-
- - add the 'lib/python' directory of your Zope installation to the
- PYTHONPATH (via sys.path.insert())
-
- - 'import ZODB' (may not be required, but just put it in for good measure)
-
- - 'import Zope'
-
- - 'app = Zope.app()'
-
- - operate on the Zope instance space by calling methods from the
- root object (bound to 'app'), e.g.:
-
- app.acl_users.manage_addUser(<parameters>)
-
- - a transaction will not be committed to the Zope object database
- until you call the global function "get_transaction().commit()",
- so changes made to the ZODB are not visible to succeeding tests
- unless that function is called explicitly.
-
- - As a part of your tearDown, make sure to call
- "app._p_jar.close()". This closes the database connection
- cleanly.
-
- For more information on operating on Zope programatically by
- "importing" it, see Michel Pelletier's "The Debugger Is Your
- Friend" at
- http://www.zope.org/Members/michel/HowTos/TheDebuggerIsYourFriend
-
- Sometimes, just importing Zope isn't enough. For example, it's
- often not possible to obtain the results of a DTML or Python method
- by simply calling it from your running code without doing lots of
- trickery by establishing fake REQUEST object to pass in to it, as
- Zope expects a REQUEST object to exist in the context of a web
- request (which a DTML method is somewhat logically designed to
- serve).
-
- If you find yourself getting bogged down while writing unit tests by
- Zope's refusal to run certain methods due to missing state (like
- REQUEST), it's useful to know about the "debug" method of the Zope
- package. This method allows you to simulate a web request, which
- generally provides all the state necessary to run methods which
- depend on web requests, and returns the results of the web request
- as it would be seen in by a web browser. To use the Zope debug
- method, do the following:
-
- - add the lib/python path to your PYTHONPATH (via sys.path.insert())
-
- - 'import ZODB'
-
- - 'import Zope'
-
- - 'Zope.debug('/a/url/representing/a/method?with=a?couple=arguments',
- u='username:password', s='silent', e={'some':'environment',
- 'variable':'settings'})
-
- The "silent" option causes Zope not to print anything. You can set
- your python's stdout to a file or a file-like object to capture the
- output if you do not set the silent flag.
-
- In Zope versions before 2.2.2, all calls to Zope.debug commit the
- transaction represented by the call to Zope.debug by default. This
- can pose problems for unit testing, as the state of the environment
- should not be effected by prior tests. A solution should be
- available by the release of Zope 2.3.
-
Administrivia
- Unit test scripts found in the Zope source code currently make use
- of the PyUnit unit testing framework, available from
+ Unit test scripts found in the Zope source code is based on
+ the PyUnit unit testing framework, available from
http://pyunit.sourceforge.net, written by Stephen Purcell (thanks
Stephen!). PyUnit is based on the JUnit testing framework for Java
(written by Kent Beck and Erich Gamma), which in turn was based on a
@@ -297,8 +234,3 @@
Programming methodologies in its software development process, we've
found unit tests a way to speed development and produce
higher-quality code.
-
- There is a testing support package in lib/python/Testing that might
- be useful to you for writing unit tests. See the README.txt in that
- directory for details.
-