Commits

Michael Foord  committed 25a4ec0

Description update

  • Participants
  • Parent commits 02d2d3b
  • Branches plugins

Comments (0)

Files changed (1)

File description.txt

     * display the time of individual tests in verbose reports
     * display a progress indicator as tests are run ([39/430] format) in verbose reports
     * allow arbitrary channels for messaging instead of just the three verbosity levels
+    * A plugin that auto-loads all plugins from a user specified directory
 
 In addition I intend to create a plugin that outputs junit compatible xml from a test run (for integration with tools like the hudson continuous integration server) and a test runner that runs tests in parallel using multiprocessing.
 
 Should it instead be called once with a MetaEvent that collects all the
 errors.
 
-startReport, reportResult and reportSummary events for customizing how the test
-run is reported?
+Inserted tests may have the "wrong" class and module, causing class and module
+level setup / teardown to be re-executed. A way of faking this, or indicating
+that they should be ignored for this purpose, should be available.
 
 The junit-xml plugin needs access to stdout / stderr for the test. This is
 only currently available if the test is run with buffering on.
 line? (This would be 'tricky' as ``handleFile`` will have to be called for the
 containing module and then the correct name pulled out of the module.)
 
-A plugin that adds a "user plugin directory" and automatically activates
-(imports) all plugins located there. New plugins can be added just by dropping
-them in the directory (zero config).
-
 The location of the user config file is not settled, and will probably need
 to be platform specific. See: http://bugs.python.org/issue7175
 
 replaced. executeTests in startTestRun should only be able to be set by one
 plugin.
 
-Inserted tests may have the "wrong" class and module, causing class and module
-level setup / teardown to be re-executed. A way of faking this, or indicating
-that they should be ignored for this purpose, should be available.
+For customising reporting there are beforeSummaryReport and afterSummaryReport events. Should there also be an event that lets you customize how reports from individual tests are output?
 
 Add an epilogue to the optparse help messages.
 
 
 Output by the TextTestRunner and the TextTestResult goes through the 'message' event. To support this the ``_WritelnDecorator`` takes an optional 'runner' argument in the constructor and has a new `write` method. If the 'runner' argument is used then all calls to `write` and `writeln` are sent on to the ``runner.message`` method (which writes directly to the underlying stream).
 
-TextTestResult has a new addReport method used by the TextTestRunner for test reporting. This adds report objects to the ``.reports`` attribute and also delegates to the standard ``addError`` / ``addFailure`` etc methods for tests with standard outcomes. For non-standard outcomes ``addReport`` reports whatever information is specified in the XXXXX
+TextTestResult has a new addReport method used by the TextTestRunner for test reporting. This adds report objects to the ``.reports`` attribute and also delegates to the standard ``addError`` / ``addFailure`` etc methods for tests with standard outcomes. Test reporting at the end of the test run is done from the reports. If a TestResult object without an ``addReport`` method is used then the old system for test reporting is used (backwards compatible).
 
 Test discovery has been improved. The initial implementation in Python 2.7 was very conservative. The new implementation supports many more common package layouts. It supports the package code being in a 'src' or a 'lib' subdirectory (that isn't itself a package). It also supports tests being in any top level directory that isn't a package, so long as the directory name contains 'test' in it.