Package: dutest
An object-oriented API to test doctests using unittest runners.Module providing classes which extend doctest module so
as to achieve better integration with unittest.It is different from the Pyhton 2.4 doctest unittest API because:A new unitest.TestLoader descendant now allows to load instances
of TestCases for doctests using unittest-style, supports building
complex test suites in a more natural way, and eases the use of
specialized instances of TestCase built out of doctest examples.Other loaders allow users to extract TestCase instances out of
TestCase descendants and doctests (and any other format) in a
single step.In this case unittest.TestResult instances report whether
individual examples have been successfully executed, or otherwise
have failed or raised an unexpected exception. Formerly TestResult
objects contained the whole report outputted by doctest module.Test analysis require no further parsing to retrieve detailed
information about failures.A whole new unittest API for doctest adds object orientation and
eliminates functions with big signatures.It is not necessary to use DocTestRunner output streams in order
to collect test results.A new hierarchy of doctest TestCases is now
possible so for example, setUp and tearDown may
be redefined across a hierarchy of TestCases
instead of providing this methods as parameters to
a function (breaking OOP philosophy and logic); or
maybe even failures and errors can be represented in a
custom way.Allows to perform regression testing over tests written
using doctest.Fixes a minor bug related with specifying different verbosity
levels from the command line to unittest.TestProgram (alias main).Loads by default test cases for doctests plus those
formerly loaded by unittest.TestLoaderIt is similar to the Pyhton 2.4 doctest unittest API because:Provides integration with TestProgram and unittest test runners.Allows to parameterize doctest behavior via doctest optionsA fuller explanation can be found in the following article:“Doctest and unittest… now they’ll live happily together”, O. Lang
(2008) The Python Papers, Volume 3, Issue 1, pp. 31:51Note: The contents of this module were first implemented by the module
oop.utils.testing contained inPyOOP package.What’s new in version 0.2.3:ImplementedSuite Fixture Setuptest pattern (i.e. set up a fixture
once before all its interactive examples are run and clean up after
they all have been run.Module is hidden in tracebacks written to instances ofTestResultwhen a failure or an error is detected.Support for multiple pattern matching styles has been added inPackageTestLoadertroughstyleparameter. By default standard
regular expressions (i.e.style=REGEX) are used.Unix filename pattern matching (fnmatchmodule) is available from
now on while usingPackageTestLoader. The only thing needed is
to specifystyle=UNIX.Multiple functions in previous versions contained arguments having
mutable objects as default values. Amessage sent to TiP list about default argsexplains why this is
really harmful. This has been fixed. Thanks to
Scott David Danielsfor reporting the issue with default argsand Jesse Noller forthe pointers about default args.What’s new in version 0.2.2:Bug fixed… The classPackageTestLoaderloaded the tests
defined in a packages’ children but not those specified in the
top-level module. Now the tests specified in the module supplied in
to loadTestsFromModule method are also included in the resulting
test suite.What’s new in version 0.2.1:PackageTestLoaderclass added to dutest module. It loads
all the tests found throughout a package hierarchy using another
loader. The later is used for retrieving the tests contained inside
every module matching a specified pattern.DocTestLoaderclass inoop.utils.dutestdoes not raiseValueErrorexception if no doctests are found in a module. This
is doctest behavior. It was assumed up to this point, but now it has
proven to be a headache when these loaders are used together with
instances ofPackageTestLoaderin order to retrieve all the
tests defined across a package hierarchy.What’s new in version 0.1.2:Bug fixed…DocTestCaseinstances could not be instantiated becauseNonewas supplied in to the initializer as the test method
name. This bug remained hidden somehow while executing the test
usingoop.test.check_oopdbc(), and even when importing
oop.utils.dutest (which is actually the same implementation).What’s new in version 0.1.1:The classoop.utils.testing.VerboseTestProgramhas been moved
onto dutest module. Release 0.1.0 did not include it. Thanks to
Michal Kwiatkowski for notifying me so[1].Default test loader and runner have been added to this module as
well. The default loader is an instance ofMultiTestLoaderthat
combines the suites loaded byunittest.TestLoaderanddutest.DocTestLoader.dutest.mainis an alias fordutest.VerboseTestProgram. This
class fixes a minor bug (… IMO) I found while specifying different
verbosity levels from the command line to unittest.TestProgram. It
also employs by defaultdutest.defaultTestLoaderinstead ofunittest.defaultTestLoader.[1][TIP] Fwd: An OO API for doctest / unittest integration…
(http://lists.idyll.org/pipermail/testing-in-python/2008-August/000918.html)What’s new in version 0.1.0:doctest / unittest extensions:A whole newunittestAPI to integratedoctestwith unittest
runners.It allows to report the individual results of each and every
interactive example executed during the test run. A separate entry
is created in the correspondingTestResultinstance containing
the expected value and the actual result.Since the match made for individual examples is reported one by one
by instances ofTestResult, it is quite easier to automate
post-testing activities (e.g. automated test analysis). Formerly
access to this information required extra work (i.e. the full report
provided by doctest had to be parsed).You do not need to useDocTestRunneroutput streams
to collect test results.A new hierarchy ofTestCasedescendants (extensions ofDocTestCaseclass) is now possible so for example,setUpandtearDownmay be redefined across a hierarchy ofTestCases
instead of providing this methods as parameters to
a function (breaking OOP philosophy and logic); or
maybe even to represent failures and errors in a
custom way.A newTestLoaderdescendant now allows to load (using
unittest-style)TestCases which check the match made for
doctests. It provides integration withTestProgram, supports
building complexTestSuites in a more natural way, and eases the
use of specialized instances ofTestCases built out of doctest
examples.Allows to perform regression testing over tests written
usingdoctest.