[pypy-svn] rev 2592 - pypy/trunk/doc/devel
sschwarzer at codespeak.net
sschwarzer at codespeak.net
Fri Dec 19 17:52:05 CET 2003
Author: sschwarzer
Date: Fri Dec 19 17:52:04 2003
New Revision: 2592
Modified:
pypy/trunk/doc/devel/testdesign.txt
Log:
Added information on new unit testing framework.
Modified: pypy/trunk/doc/devel/testdesign.txt
==============================================================================
--- pypy/trunk/doc/devel/testdesign.txt (original)
+++ pypy/trunk/doc/devel/testdesign.txt Fri Dec 19 17:52:04 2003
@@ -6,8 +6,8 @@
in a directory usually reside in a subdirectory **test**. There are
basically two types of unit tests:
-- **Interpreter Level tests**. They run at the same level as PyPy's
- interpreter.
+- **Interpreter Level tests**. They run at the same level as PyPy's
+ interpreter.
- **Application Level tests**. They run at application level which means
that they look like straight python code but they are interpreted by PyPy.
@@ -15,12 +15,12 @@
Both types of tests need an object-space they can run with (the interpreter
dispatches operations on objects to an objectspace). If you run a test you
can usually give the '-S', '-T' or '-A' switch for using the Standard, Trivial
-or Ann-ObjectSpace respectively.
+or Ann-ObjectSpace respectively.
-Writing a test
+Writing a test
--------------
-The best reference is to go to some test files and look how they are done.
+The best reference is to go to some test files and look how they are done.
Almost all tests start with the following lines::
import autopath
@@ -30,7 +30,7 @@
for **pypy** among the parents of the test-file's directory. The second
line imports PyPy's test-hook of which ''test.main()'' is the most important
and is usually the last line of the testfile. For more info please refer to
-a pypy-dev mail_ where the current testing framework was introduced.
+a pypy-dev mail_ where the current testing framework was introduced.
Command line tool test_all
--------------------------
@@ -39,7 +39,7 @@
python test_all.py
-which will run all tests against the Trivial Object Space. If you want
+which will run all tests against the Trivial Object Space. If you want
to test against the StandardObjectSpace then issue::
python test_all.py -S
@@ -49,3 +49,83 @@
-------------------------------------------------------------------------------
.. _mail: http://codespeak.net/pipermail/pypy-dev/2003q2/000789.html
+
+New unit testing framework (not ready yet)
+------------------------------------------
+
+Current implementation
+~~~~~~~~~~~~~~~~~~~~~~
+
+The following picture is an UML class diagram of the framework. This
+diagram is taken from the source code, which can currently be found
+at src/pypy/tool/newtest.py as of 2003-12-19. (Most probably, the name
+of the file will change, however.)
+
+::
+
+ +------------+ 1 1 +----------+
+ | TestResult |----------------------------------------| TestItem |
+ | (abstract) | +----------+
+ +------------+ | *
+ A |
+ - |
+ | | 1
+ +----------------------------+-----------+ +-----------+
+ | | | | TestSuite |
+ +-------------------------+ +---------+ +---------+ +-----------+
+ | TestResultWithTraceback | | Success | | Skipped | A
+ | (abstract) | +---------+ +---------+ |
+ +-------------------------+ | loaded by
+ A A |
+ - - | *
+ | | +------------+
+ | | | TestCase |
+ +-------+ +---------+ | (abstract) |
+ | Error | | Failure | +------------+
+ +-------+ +---------+ A
+ -
+ |
+ |
+ concrete test
+ case classes
+
+Like the unittest framework of Python, our framework implements
+tests as test methods in TestCase classes. Custom test case classes
+derive from the shown TestCase class, defined in this module. As in
+Python's unittest, a test case class can contain setUp and tearDown
+methods. Additionally, it contains a method 'skip' which can be
+called to stop a test prematurely. This won't be counted as a failure
+or error.
+
+Test cases are loaded by a TestSuite class via the method init_from_dir.
+This method will read all test modules in and below a specified
+directory, inspect them for classes derived from TestCase (i. e. *our*
+TestCase), and in turn inspect them for test methods (like in
+unittest, all methods which start with "test").
+
+For every found method, TestSuite will store its module, class and
+unbound method objects in a TestItem object. There are also other
+properties stored, e. g. the source code for each method and its
+docstring.
+
+When the TestSuite's method 'run' is called, all collected TestItems
+are run and, according to the outcome of the test, a TestResult object
+is generated which holds a reference to "its" TestItem object.
+
+The TestResult classes Success and Skipped denote a passed test. A
+skipped test means that not all test code has been run (and no error
+or failure occurred before the skip method was called). If a test
+fails, resulting in a Failure object, a test, e. g. tested with
+assertEqual, has failed. An Error object is generated if something
+else causes an unforeseen exception to be raised.
+
+Outlook
+~~~~~~~
+
+To be directly usable for the PyPy project, the selection of specific
+object spaces has to be implemented. Moreover, the existing test
+modules have to be converted. Because the TestCase class interface
+remains compatible, this should only involve changes which can be
+performed automatically, that is, changing the import statement for
+this test module and the base class of test cases.
+
More information about the Pypy-commit
mailing list