1 | nose collects tests automatically from python source files, |
---|
2 | directories and packages found in its working directory (which |
---|
3 | defaults to the current working directory). Any python source file, |
---|
4 | directory or package that matches the testMatch regular expression |
---|
5 | (by default: `(?:^|[\b_\.-])[Tt]est)` will be collected as a test (or |
---|
6 | source for collection of tests). In addition, all other packages |
---|
7 | found in the working directory will be examined for python source files |
---|
8 | or directories that match testMatch. Package discovery descends all |
---|
9 | the way down the tree, so package.tests and package.sub.tests and |
---|
10 | package.sub.sub2.tests will all be collected. |
---|
11 | |
---|
12 | Within a test directory or package, any python source file matching |
---|
13 | testMatch will be examined for test cases. Within a test module, |
---|
14 | functions and classes whose names match testMatch and TestCase |
---|
15 | subclasses with any name will be loaded and executed as tests. Tests |
---|
16 | may use the assert keyword or raise AssertionErrors to indicate test |
---|
17 | failure. TestCase subclasses may do the same or use the various |
---|
18 | TestCase methods available. |
---|
19 | |
---|
20 | Selecting Tests |
---|
21 | --------------- |
---|
22 | |
---|
23 | To specify which tests to run, pass test names on the command line: |
---|
24 | |
---|
25 | %prog only_test_this.py |
---|
26 | |
---|
27 | Test names specified may be file or module names, and may optionally |
---|
28 | indicate the test case to run by separating the module or file name |
---|
29 | from the test case name with a colon. Filenames may be relative or |
---|
30 | absolute. Examples: |
---|
31 | |
---|
32 | %prog test.module |
---|
33 | %prog another.test:TestCase.test_method |
---|
34 | %prog a.test:TestCase |
---|
35 | %prog /path/to/test/file.py:test_function |
---|
36 | |
---|
37 | You may also change the working directory where nose looks for tests |
---|
38 | by using the -w switch: |
---|
39 | |
---|
40 | %prog -w /path/to/tests |
---|
41 | |
---|
42 | Note, however, that support for multiple -w arguments is now deprecated |
---|
43 | and will be removed in a future release. As of nose 0.10, you can get |
---|
44 | the same behavior by specifying the target directories *without* |
---|
45 | the -w switch: |
---|
46 | |
---|
47 | %prog /path/to/tests /another/path/to/tests |
---|
48 | |
---|
49 | Further customization of test selection and loading is possible |
---|
50 | through the use of plugins. |
---|
51 | |
---|
52 | Test result output is identical to that of unittest, except for |
---|
53 | the additional features (error classes, and plugin-supplied |
---|
54 | features such as output capture and assert introspection) detailed |
---|
55 | in the options below. |
---|
56 | |
---|
57 | Configuration |
---|
58 | ------------- |
---|
59 | |
---|
60 | In addition to passing command-line options, you may also put |
---|
61 | configuration options in a .noserc or nose.cfg file in your home |
---|
62 | directory. These are standard .ini-style config files. Put your |
---|
63 | nosetests configuration in a [nosetests] section. Options are the |
---|
64 | same as on the command line, with the -- prefix removed. For |
---|
65 | options that are simple switches, you must supply a value: |
---|
66 | |
---|
67 | [nosetests] |
---|
68 | verbosity=3 |
---|
69 | with-doctest=1 |
---|
70 | |
---|
71 | All configuration files that are found will be loaded and their options |
---|
72 | combined. |
---|
73 | |
---|
74 | Using Plugins |
---|
75 | ------------- |
---|
76 | |
---|
77 | There are numerous nose plugins available via easy_install and |
---|
78 | elsewhere. To use a plugin, just install it. The plugin will add |
---|
79 | command line options to nosetests. To verify that the plugin is installed, |
---|
80 | run: |
---|
81 | |
---|
82 | nosetests --plugins |
---|
83 | |
---|
84 | You can add -v or -vv to that command to show more information |
---|
85 | about each plugin. |
---|
86 | |
---|
87 | If you are running nose.main() or nose.run() from a script, you |
---|
88 | can specify a list of plugins to use by passing a list of plugins |
---|
89 | with the plugins keyword argument. |
---|
90 | |
---|
91 | 0.9 plugins |
---|
92 | ----------- |
---|
93 | |
---|
94 | nose 0.11 can use SOME plugins that were written for nose 0.9. The |
---|
95 | default plugin manager inserts a compatibility wrapper around 0.9 |
---|
96 | plugins that adapts the changed plugin api calls. However, plugins |
---|
97 | that access nose internals are likely to fail, especially if they |
---|
98 | attempt to access test case or test suite classes. For example, |
---|
99 | plugins that try to determine if a test passed to startTest is an |
---|
100 | individual test or a suite will fail, partly because suites are no |
---|
101 | longer passed to startTest and partly because it's likely that the |
---|
102 | plugin is trying to find out if the test is an instance of a class |
---|
103 | that no longer exists. |
---|
104 | |
---|
105 | 0.10 plugins |
---|
106 | ------------ |
---|
107 | |
---|
108 | All plugins written for nose 0.10 should work with nose 0.11. |
---|