Skip to content

Latest commit

 

History

History
210 lines (147 loc) · 6.55 KB

configuration.rst

File metadata and controls

210 lines (147 loc) · 6.55 KB

Configuring nose2

Configuration Files

Most configuration of nose2 is done via config files. These are standard, .ini-style config files, with sections marked off by brackets ("[unittest]") and key = value pairs within those sections.

Two command line options, -c and --no-user-config may be used to determine which config files are loaded.

Configuring Test Discovery

The [unittest] section of nose2 config files is used to configure nose2 itself. The following options are available to configure test discovery:

Examples:

Specifying Plugins to Load

To avoid loading any plugins, use the --no-plugins option. Beware, though: nose2 does all test discovery and loading via plugins, so unless you are patching in a custom test loader and runner, when run with --no-plugins, nose2 will do nothing.

To specify plugins to load beyond the builtin plugins automatically loaded, add a plugins entry under the [unittest] section in a config file.

To exclude some plugins that would otherwise be loaded, add an exclude-plugins entry under the [unittest] section in a config file.

Examples:

Configuring Plugins

Most plugins specify a config file section that may be used to configure the plugin. If nothing else, any plugin that specifies a config file section can be set to automatically register by including always-on = True in its config:

Plugins may accept any number of other config values, which may be booleans, strings, integers or lists. A polite plugin will document these options somewhere. Plugins that want to make use of nose2's Sphinx extension as detailed in dev/documenting_plugins must extract all of their config values in their __init__ methods.

Test Runner Tips and Tweaks

Running Tests in a Single Module

You can use nose2.main in the same way that unittest.main (and unittest2.main) have historically worked: to run the tests in a single module. Just put a block like the following at the end of the module:

if __name__ == '__main__':
    import nose2
    nose2.main()

Then run the module directly -- In other words, do not run the nose2 script.

Rolling Your Own Runner

You can take more control over the test runner by foregoing the nose2 script and rolling your own. To do that, you just need to write a script that calls nose2.discover, for instance:

if __name__ == '__main__':
  import nose2
  nose2.discover()

You can pass several keyword arguments to nose2.discover, all of which are detailed in the documentation for nose2.main.PluggableTestProgram.

Altering the Default Plugin Set

To add plugin modules to the list of those automatically loaded, you can pass a list of module names to add (the plugins) argument or exclude (excludedPlugins). You can also subclass nose2.main.PluggableTestProgram and set the class-level defaultPlugins and excludePlugins attributes to alter plugin loading.

When Loading Plugins from Modules is not Enough

None of which will help if you need to register a plugin instance that you've loaded yourself. For that, use the extraHooks keyword argument to nose2.discover. Here, you pass in a list of 2-tuples, each of which contains a hook name and a plugin instance to register for that hook. This allows you to register plugins that need runtime configuration that is not easily passed in through normal channels --and also to register objects that are not nose2 plugins as hook targets. Here's a trivial example:

if __name__ == '__main__':
  import nose2

  class Hello(object):
      def startTestRun(self, event):
          print("hello!")

  nose2.discover(extraHooks=[('startTestRun', Hello())])

This can come in handy when integrating with other systems that expect you to provide a test runner that they execute, rather than executing tests yourself (django, for instance).