This manual page is for Mac OS X version 10.6.3

If you are running a different version of Mac OS X, view the documentation locally:

  • In Terminal, using the man(1) command

Reading manual pages

Manual pages are intended as a quick reference for people who already understand a technology.

  • For more information about the manual page format, see the manual page for manpages(5).

  • For more information about this technology, look for other documentation in the Apple Reference Library.

  • For general information about writing shell scripts, read Shell Scripting Primer.



TRIAL(1)                                                                                            TRIAL(1)



NAME
       trial - run unit tests

SYNOPSIS
       trial [options] [[file|package|module|TestCase|testmethod]...]

       trial --help

DESCRIPTION
       trial  loads  and executes a suite of unit tests, obtained from modules, packages and files listed on
       the command line.

       trial will take either filenames or fully qualified Python names as arguments.   Thus  'trial  mypro-ject/foo.py', myproject/foo.py',
       ject/foo.py', 'trial myproject.foo' and
        'trial myproject.foo.SomeTestCase.test_method' are all valid ways to invoke trial.

       -b, --debug
              Run the tests in the Python debugger. Also does post-mortem debugging on exceptions. Will load
              '.pdbrc' from current directory if it exists.

       -B, --debug-stacktraces
              Report Deferred creation and callback stack traces

       --coverage
              Generate coverage information in _trial_temp/coverage/. Requires Python 2.3 or higher.

       --disablegc
              Disable the garbage collector.  I don't know why this is in trial.

       -x, --extra
              Add an extra argument. (This is a hack necessary for interfacing with emacs's `gud'.)

       -e, --rterrors
              Print tracebacks to standard output as soon as they occur

       --force-gc
              Run gc.collect() before and after each test case. This can be  used  to  isolate  errors  that
              occur when objects get collected.  This option would be the default, except it makes tests run
              about ten times slower.

       -h, --help
              Print a usage message to standard output, then exit.

       --help-reporters
              Print a list of valid reporters to standard output, then exit.

       --help-reactors
              List the names of possibly available reactors.

       -l, --logfile <logfile>
              Direct the log to a different file. The default file is 'test.log'.  <logfile> is relative  to
              _trial_temp.

       -n, --dry-run
              Go through all the tests and make them pass without running.

       -N, --no-recurse
              By  default,  trial  recurses  through  packages to find every module inside every subpackage.
              Unless, that is, you specify this option.

       --nopm Don't automatically jump into debugger for post-mortem analysis of exceptions.  Only usable in
              conjunction with --debug.

       --profile
              Run tests under the Python profiler.

       -r, --reactor <reactor>
              Choose which reactor to use.  See --help-reactors for a list.

       --recursionlimit
              Set Python's recursion limit. See sys.setrecursionlimit()

       --reporter
              Select  the reporter to use for Trial's output.  Use the --help-reporters option to see a list
              of valid reporters.

       --spew Print an insanely verbose log of everything that happens. Useful  when  debugging  freezes  or
              locks in complex code.

       --tbformat <format>
              Format  to  display  tracebacks  with. Acceptable values are 'default', 'brief' and 'verbose'.
              'brief' produces tracebacks that play nicely with Emacs' GUD.

       --temp-directory <directory>
              WARNING: Do not use this options unless you know what you are doing.  By default,  trial  cre-ates creates
              ates  a directory called _trial_temp under the current working directory.  When trial runs, it
              first deletes this directory, then creates it, then changes into  the  directory  to  run  the
              tests.  The  log  file  and any coverage files are stored here. Use this option if you wish to
              have trial run in a directory other than _trial_temp. Be warned, trial will delete the  direc-tory directory
              tory before re-creating it.

       --testmodule <filename>
              Ask  trial  to  look  into <filename> and run any tests specified using the Emacs-style buffer
              variable 'test-case-name'.

       --unclean-warnings
              As of Twisted 8.0, trial will report an error if the reactor is left unclean at the end of the
              test.  This  option  is  provided  to  assist in migrating from Twisted 2.5 to Twisted 8.0 and
              later. Enabling this option will turn the errors into warnings.

       -u, --until-failure
              Keep looping the tests until one of them raises an error or a failure.  This  is  particularly
              useful for reproducing intermittent failures.

       --version
              Prints the Twisted version number and exit.

       --without-module <modulenames>
              Simulate  the  lack  of the specified comma-separated list of modules. This makes it look like
              the modules are not present in the system, causing tests to check the behavior for  that  con-figuration. configuration.
              figuration.

       -z, --random [<seed>]
              Run the tests in random order using the specified seed.


AUTHOR
       Written by Jonathan M. Lange

REPORTING BUGS
       To report a bug, visit http://twistedmatrix.com/bugs/

COPYRIGHT
       Copyright (C) 2003-2008 Twisted Matrix Laboratories
       This  is  free  software;  see the source for copying conditions.  There is NO warranty; not even for
       MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



                                                  Oct 2007                                          TRIAL(1)

Reporting Problems

The way to report a problem with this manual page depends on the type of problem:

Content errors
Report errors in the content of this documentation with the feedback links below.
Bug reports
Report bugs in the functionality of the described tool or API through Bug Reporter.
Formatting problems
Report formatting mistakes in the online version of these pages with the feedback links below.

Did this document help you? Yes It's good, but... Not helpful...