Linux "trial3" Command Line Options and Examples
run unit tests

trial loads and executes a suite of unit tests, obtained from modules, packages and files listed on the com‐ mand line. trial will take either filenames or fully qualified Python names as arguments. Thus `trial myproject/foo.


Usage:

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


    trial --help | -h




Command Line Options:

-j
Set the number of process workers to run. It conflicts with the debug, exitfirst and profile options.
trial3 -j ...
-b
Run the tests in a debugger. If that debugger is 'pdb' (which is the default if unspecified), a`.pdbrc' will be loaded from the current directory if it exists. Also does post-mortem debugging onexceptions.
trial3 -b ...
-B
Report Deferred creation and callback stack traces.
trial3 -B ...
--coverage
Generate coverage information in the `coverage' subdirectory of the trial temp directory (`_trial_temp'by default). For each Python module touched by the execution of the given tests, a file will be createdin the coverage directory named for the module's fully-qualified name with the suffix `.cover'. Forexample, because the trial test runner is written in Python, the coverage directory will almost alwayscontain a file named `twisted.trial.runner.cover'.Each `.cover' file contains a copy of the Python source of the module in question, with a prefix at thebeginning of each line containing coverage information. For lines that are not executable (blanklines, comments, etc.) the prefix is blank. For executable lines that were run in the course of thetest suite, the prefix is a number indicating the number of times that line was executed. The string`>>>>>>' prefixes executable lines that were not executed in the course of the test suite.Note that this functionality uses Python's sys.settrace() function, so tests that call sys.settrace()themselves are likely to break trial's coverage functionality.
trial3 --coverage ...
--debugger
Specifies the debugger to use when the --debug option is passed. The argument should be the fully qual‐ified name of an object that implements the same interface as the standard library's `pdb'.
trial3 --debugger ...
--disablegc
Disable the garbage collector for the duration of the test run. As each test is run, trial saves theTestResult objects, which means that Python's garbage collector has more non-garbage objects to wadethrough, making each garbage-collection run slightly slower. Disabling garbage collection entirely willmake some test suites complete faster (contrast --force-gc, below), at the cost of increasing (possiblygreatly) memory consumption. This option also makes tests slightly more deterministic, which might helpdebugging in extreme circumstances.
trial3 --disablegc ...
-e
Print tracebacks to standard output as soon as they occur.
trial3 -e ...
--force-gc
Run gc.collect() before and after each test case. This can be used to isolate errors that occur whenobjects get collected. This option would be the default, except it makes tests run about ten timesslower.
trial3 --force-gc ...
-h
Print a usage message to standard output, then exit.
trial3 -h ...
--help-order
Print a list of possible orders that TestCase test methods can be run in, then exit. The orders can beused with the --order option described below.
trial3 --help-order ...
--help-reporters
Print a list of valid reporters to standard output, then exit. Reporters can be selected with the
trial3 --help-reporters ...
--reporter
option described below.
trial3 --reporter ...
--help-reactors
Print a list of possible reactors to standard output, then exit. Not all listed reactors are availableon every platform. Reactors can be selected with the --reactor option described below.
trial3 --help-reactors ...
-l
Direct the log to a different file. The default file is `test.log'. logfile is relative to_trial_temp.
trial3 -l ...
-n
Go through all the tests and make them pass without running.
trial3 -n ...
-N
By default, trial recurses through packages to find every module inside every subpackage. Unless, thatis, you specify this option.
trial3 -N ...
--order
Specify what order to run the individual test methods within the given TestCases. By default, they arerun alphabetically. See --help-order for a list of other valid values.
trial3 --order ...
--profile
Run tests under the Python profiler.
trial3 --profile ...
-r
Choose which reactor to use. See --help-reactors for a list.
trial3 -r ...
--recursionlimit
Set Python's recursion limit. See sys.setrecursionlimit().
trial3 --recursionlimit ...
-x
Stop the test run after the first test which does not succeed. This includes failures, errors, or unex‐pected successes. Won't work with the --jobs option currently.
trial3 -x ...
--tbformat
Format to display tracebacks with. Acceptable values are `default', `brief' and `verbose'. `brief' pro‐duces tracebacks that play nicely with Emacs' GUD.
trial3 --tbformat ...
--temp-directory
WARNING: Do not use this option unless you know what you are doing. By default, trial creates a direc‐tory called _trial_temp under the current working directory. When trial runs, it first deletes thisdirectory, then creates it, then changes into the directory to run the tests. The log file and any cov‐erage 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 directory before re-creating it.
trial3 --temp-directory ...
--testmodule
Ask trial to look into filename and run any tests specified using the Emacs-style buffer variable`test-case-name'.
trial3 --testmodule ...
--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 thisoption will turn the errors into warnings.
trial3 --unclean-warnings ...
-u
Keep looping the tests until one of them raises an error or a failure. This is particularly useful forreproducing intermittent failures.
trial3 -u ...
--version
Prints the Twisted version number and exit.
trial3 --version ...
--without-module
Simulate the lack of the specified comma-separated list of modules. This makes it look like the modulesare not present in the system, causing tests to check the behavior for that configuration.
trial3 --without-module ...
-z
Run the tests in random order using the specified seed. Don't pass this option if you also are passing
trial3 -z ...