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

.. [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 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**.

