Not Logged In

dutest 0.2.4

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.TestLoader

What’s new in version 0.2.2:

Bug fixed… The class PackageTestLoader loaded 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:

PackageTestLoader class 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.

DocTestLoader class in oop.utils.dutest does not raise
ValueError exception 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 of PackageTestLoader in order to retrieve all the
tests defined across a package hierarchy.

What’s new in version 0.1.2:

Bug fixed… DocTestCase instances could not be instantiated because
None was supplied in to the initializer as the test method
name. This bug remained hidden somehow while executing the test
using oop.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 class oop.utils.testing.VerboseTestProgram has 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 of MultiTestLoader that
combines the suites loaded by unittest.TestLoader and
dutest.DocTestLoader.

dutest.main is an alias for dutest.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 default dutest.defaultTestLoader instead of
unittest.defaultTestLoader.

What’s new in version 0.1.0:

doctest / unittest extensions:

A whole new unittest API to integrate doctest with 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 corresponding TestResult instance containing
the expected value and the actual result.

Since the match made for individual examples is reported one by one
by instances of TestResult, 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 use DocTestRunner output streams
to collect test results.

A new hierarchy of TestCase descendants (extensions of
DocTestCase class) is now possible so for example, setUp and
tearDown may be redefined across a hierarchy of TestCase s
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 new TestLoader descendant now allows to load (using
unittest-style) TestCase s which check the match made for
doctests. It provides integration with TestProgram, supports
building complex TestSuite s in a more natural way, and eases the
use of specialized instances of TestCase s built out of doctest
examples.

Allows to perform regression testing over tests written
using doctest.