OLD | NEW |
| (Empty) |
1 # Copyright (c) 2001-2004 Twisted Matrix Laboratories. | |
2 # See LICENSE for details. | |
3 # | |
4 # Maintainer: Jonathan Lange <jml@twistedmatrix.com> | |
5 | |
6 """ | |
7 Asynchronous unit testing framework. | |
8 | |
9 Trial extends Python's builtin C{unittest} to provide support for asynchronous | |
10 tests. | |
11 | |
12 Maintainer: Jonathan Lange <jml@twistedmatrix.com> | |
13 | |
14 Trial strives to be compatible with other Python xUnit testing frameworks. | |
15 "Compatibility" is a difficult things to define. In practice, it means that: | |
16 | |
17 - L{twisted.trial.unittest.TestCase} objects should be able to be used by | |
18 other test runners without those runners requiring special support for | |
19 Trial tests. | |
20 | |
21 - Tests that subclass the standard library C{TestCase} and don't do anything | |
22 "too weird" should be able to be discoverable and runnable by the Trial | |
23 test runner without the authors of those tests having to jump through | |
24 hoops. | |
25 | |
26 - Tests that implement the interface provided by the standard library | |
27 C{TestCase} should be runnable by the Trial runner. | |
28 | |
29 - The Trial test runner and Trial L{unittest.TestCase} objects ought to be | |
30 able to use standard library C{TestResult} objects, and third party | |
31 C{TestResult} objects based on the standard library. | |
32 | |
33 This list is not necessarily exhaustive -- compatibility is hard to define. | |
34 Contributors who discover more helpful ways of defining compatibility are | |
35 encouraged to update this document. | |
36 | |
37 | |
38 Examples: | |
39 | |
40 B{Timeouts} for tests should be implemented in the runner. If this is done, | |
41 then timeouts could work for third-party TestCase objects as well as for | |
42 L{twisted.trial.unittest.TestCase} objects. Further, Twisted C{TestCase} | |
43 objects will run in other runners without timing out. | |
44 See U{http://twistedmatrix.com/trac/ticket/2675}. | |
45 | |
46 Running tests in a temporary directory should be a feature of the test case, | |
47 because often tests themselves rely on this behaviour. If the feature is | |
48 implemented in the runner, then tests will change behaviour (possibly | |
49 breaking) when run in a different test runner. Further, many tests don't even | |
50 care about the filesystem. | |
51 See U{http://twistedmatrix.com/trac/ticket/2916}. | |
52 """ | |
OLD | NEW |