nose/usage.txt

   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 your project's *setup.cfg* file, or a .noserc
  62 or nose.cfg file in your home directory. In any of these standard
  63 .ini-style config files, you put your nosetests configuration in a
  64 ``[nosetests]`` section. Options are the same as on the command line,
  65 with the -- prefix removed. For options that are simple switches, you
  66 must supply a value:
  67
  68   [nosetests]
  69   verbosity=3
  70   with-doctest=1
  71
  72 All configuration files that are found will be loaded and their
  73 options combined. You can override the standard config file loading
  74 with the ``-c`` option.
  75
  76 Using Plugins
  77 -------------
  78
  79 There are numerous nose plugins available via easy_install and
  80 elsewhere. To use a plugin, just install it. The plugin will add
  81 command line options to nosetests. To verify that the plugin is installed,
  82 run:
  83
  84   nosetests --plugins
  85
  86 You can add -v or -vv to that command to show more information
  87 about each plugin.
  88
  89 If you are running nose.main() or nose.run() from a script, you
  90 can specify a list of plugins to use by passing a list of plugins
  91 with the plugins keyword argument.
  92
  93 0.9 plugins
  94 -----------
  95
  96 nose 1.0 can use SOME plugins that were written for nose 0.9. The
  97 default plugin manager inserts a compatibility wrapper around 0.9
  98 plugins that adapts the changed plugin api calls. However, plugins
  99 that access nose internals are likely to fail, especially if they
 100 attempt to access test case or test suite classes. For example,
 101 plugins that try to determine if a test passed to startTest is an
 102 individual test or a suite will fail, partly because suites are no
 103 longer passed to startTest and partly because it's likely that the
 104 plugin is trying to find out if the test is an instance of a class
 105 that no longer exists.
 106
 107 0.10 and 0.11 plugins
 108 ---------------------
 109
 110 All plugins written for nose 0.10 and 0.11 should work with nose 1.0.