Dropping Into the Debugger¶
│ │ │ -Start a pdb.post_mortem()
on errors and failures.
Start a pdb.post_mortem()
on errors and failures.
This plugin implements testOutcome()
and will drop into pdb
│ │ │ whenever it sees a test outcome that includes exc_info.
It fires beforeInteraction()
before launching pdb and
│ │ │ afterInteraction()
after. Other plugins may implement
│ │ │ beforeInteraction()
to return False
and set event.handled
to
│ │ │ prevent this plugin from launching pdb.
Layer method reference¶
│ │ │-
│ │ │
-
│ │ │ class
Layer
¶
│ │ │ Not an actual class, but reference documentation for │ │ │ the methods layers can implement. There is no layer │ │ │ -base class. Layers must be subclasses of
│ │ │object
│ │ │ +base class. Layers must be subclasses ofobject
│ │ │ or other layers.-
│ │ │
-
│ │ │ classmethod
setUp
(cls)¶
│ │ │ The layer’s
setUp
method is called before any tests belonging to │ │ │ that layer are executed. If no tests belong to the layer (or one of │ │ │ its sub-layers) then thesetUp
method will not │ │ │ @@ -423,15 +423,15 @@ │ │ ││ │ ││ │ │Mixing layers with
│ │ │setUpClass
and module fixtures¶Don’t cross the streams.
│ │ │The implementation of class- and module-level fixtures in unittest2 │ │ │ depends on introspecting the class hierarchy inside of the │ │ │
│ │ │unittest.TestSuite
. Since the suites that thelayers
plugin uses to │ │ │ organize tests derive fromunittest.BaseTestSuite
(instead of │ │ │ -unittest.TestSuite
), class- and module- level fixtures in │ │ │ +unittest.TestSuite
), class- and module- level fixtures in │ │ │ TestCase classes that use layers will be ignored.│ │ ││ │ ├── ./usr/share/doc/python-nose2/html/plugins/testcases.html │ │ │ @@ -197,18 +197,18 @@ │ │ │Mixing layers and multiprocess testing¶
│ │ │In the initial release, test suites using layers are incompatible with │ │ │ the multiprocess plugin. This should be fixed in a future release.
│ │ │
│ │ │
-
│ │ │ classmethod
Loader: Test Cases¶
│ │ │ -Load tests from unittest.TestCase
subclasses.
Load tests from unittest.TestCase
subclasses.
This plugin implements loadTestsFromName()
and
│ │ │ loadTestsFromModule()
to load tests from
│ │ │ -unittest.TestCase
subclasses found in modules or named on the
│ │ │ +unittest.TestCase
subclasses found in modules or named on the
│ │ │ command line.
Configuration [testcases]¶
│ │ │-
│ │ │
-
│ │ │
always-on
¶
│ │ │ -
│ │ │ @@ -235,15 +235,15 @@
│ │ │
-
│ │ │ class
nose2.plugins.loader.testcases.
TestCaseLoader
(*args, **kwargs)[source]¶
│ │ │ Loader plugin that loads from test cases
│ │ │-
│ │ │
-
│ │ │
loadTestsFromModule
(event)[source]¶
│ │ │ - Load tests in
│ │ │ +unittest.TestCase
subclassesLoad tests in
│ │ │unittest.TestCase
subclasses
-
│ │ │
-
│ │ │
loadTestsFromName
(event)[source]¶
│ │ │ Load tests from event.name if it names a test case/method
│ │ │
│ │ │-
│ │ │
-
│ │ │
-
│ │ │ class
Loader: Test Classes¶
│ │ │ -Load tests from classes that are not unittest.TestCase
subclasses.
Load tests from classes that are not unittest.TestCase
subclasses.
This plugin responds to loadTestsFromModule()
by adding test
│ │ │ cases for test methods found in classes in the module that are not
│ │ │ -sublcasses of unittest.TestCase
, but whose names (lowercased)
│ │ │ +sublcasses of unittest.TestCase
, but whose names (lowercased)
│ │ │ match the configured test method prefix.
Test class methods that are generators or have param lists are not
│ │ │ loaded here, but by the nose2.plugins.loader.generators.Generators
and
│ │ │ nose2.plugins.loader.parameters.Parameters
plugins.
This plugin also implements loadTestsFromName()
to enable
│ │ │ loading tests from dotted class and method names passed on the command
│ │ │ line.
nose2.plugins.loader.testclasses.
loadTestsFromTestClass
(self, event)¶
│ │ │ -
│ │ │
- Parameters │ │ │
event – A
│ │ │LoadFromTestClassEvent
instance
│ │ │
Plugins can use this hook to load tests from a class that is not a
│ │ │ -unittest.TestCase
subclass. To prevent other plugins from
│ │ │ +unittest.TestCase
subclass. To prevent other plugins from
│ │ │ loading tests from the test class, set event.handled
to True
and
│ │ │ return a test suite. Plugins can also append tests to
│ │ │ event.extraTests
. Ususally, that’s what you want, since
│ │ │ it allows other plugins to load their tests from the test
│ │ │ case as well.
-
│ │ │
- Parameters │ │ │
event – A
│ │ │GetTestMethodNamesEvent
instance
│ │ │
Plugins can use this hook to limit or extend the list of test case
│ │ │ names that will be loaded from a class that is not a
│ │ │ -unittest.TestCase
subclass by the standard nose2 test
│ │ │ +unittest.TestCase
subclass by the standard nose2 test
│ │ │ loader plugins (and other plugins that respect the results of the
│ │ │ hook). To force a specific list of names, set event.handled
to
│ │ │ True
and return a list: this exact list will be the only test case
│ │ │ names loaded from the test case. Plugins can also extend the list
│ │ │ of names by appending test names to event.extraNames
, and
│ │ │ exclude names by appending test names to event.excludedNames
.
About Test Classes¶
│ │ │Test classes are classes that look test-like but are not subclasses of
│ │ │ -unittest.TestCase
. Test classes support all of the same test
│ │ │ +unittest.TestCase
. Test classes support all of the same test
│ │ │ types and fixtures as test cases.
To “look test-like” a class must have a name that, lowercased, matches │ │ │ the configured test method prefix – “test” by default. Test classes │ │ │ must also be able to be instantiated without arguments.
│ │ │What are they useful for? Mostly the case where a test class can’t for
│ │ │ -some reason subclass unittest.TestCase
. Otherwise, test class
│ │ │ +some reason subclass unittest.TestCase
. Otherwise, test class
│ │ │ tests and test cases are functionally equivalent in nose2, and test
│ │ │ cases have broader support and all of those helpful assert* methods
│ │ │ -– so when in doubt, you should use a unittest.TestCase
.
unittest.TestCase
.
│ │ │ Here’s an example of a test class:
│ │ │class TestSomething(object):
│ │ │
│ │ │ def test(self):
│ │ │ assert self.something(), "Something failed!"
│ │ │
And tests are likewise marked with the should
decorator:
@it.should('exhibit the behavior described here')
│ │ │ def test(case):
│ │ │ # ...
│ │ │
Test cases may optionally take one argument. If they do, they will be
│ │ │ -passed the unittest.TestCase
instance generated for the
│ │ │ +passed the unittest.TestCase
instance generated for the
│ │ │ test. They can use this TestCase
instance to execute assert methods,
│ │ │ among other things. Test functions can also call assert methods on the
│ │ │ top-level scenario instance, if they don’t take the case
argument:
@it.should("be able to use the scenario's assert methods")
│ │ │ def test():
│ │ │ it.assertEqual(something, 'a value')
│ │ │
│ │ │ @@ -442,15 +442,15 @@
│ │ │
Finally, to actually generate tests, you must call createTests
on
│ │ │ the top-level scenario instance:
it.createTests(globals())
│ │ │
This call generates the unittest.TestCase
instances for all
│ │ │ +
This call generates the unittest.TestCase
instances for all
│ │ │ of the tests, and the layer classes that hold the fixtures defined in
│ │ │ the test groups. See Organizing Test Fixtures into Layers for more about test
│ │ │ layers.
Running tests¶
│ │ │Since order is often significant in functional tests, such DSL tests │ │ │ always execute in the order in which they are defined in the │ │ │ @@ -509,15 +509,15 @@ │ │ │ that depend on those fixtures.
│ │ │-
│ │ │
-
│ │ │
createTests
(mod)[source]¶
│ │ │ Generate test cases for this scenario.
│ │ ││ │ ││ │ │Warning
│ │ │ -You must call this, passing in
globals()
, to │ │ │ +You must call this, passing in
│ │ │globals()
, to │ │ │ generate tests from the scenario. If you don’t, │ │ │ no tests will be created.│ │ ││ │ │it.createTests(globals()) │ │ │
Add a test case setup()
method to this group.
The setup()
method will run before each of the
│ │ │ tests in the containing group.
A group may define any number of test case setup()
│ │ │ functions. They will execute in the order in which they are
│ │ │ defined.
Test setup()
functions may optionally take one argument. If
│ │ │ -they do, they will be passed the unittest.TestCase
│ │ │ +they do, they will be passed the unittest.TestCase
│ │ │ instance generated for the test.
@it.has_test_setup
│ │ │ def setup(case):
│ │ │ # ...
│ │ │
Add a test case teardown()
method to this group.
The teardown()
method will run before each of the
│ │ │ tests in the containing group.
A group may define any number of test case teardown()
│ │ │ functions. They will execute in the order in which they are
│ │ │ defined.
Test teardown()
functions may optionally take one argument. If
│ │ │ -they do, they will be passed the unittest.TestCase
│ │ │ +they do, they will be passed the unittest.TestCase
│ │ │ instance generated for the test.
@it.has_test_teardown
│ │ │ def teardown(case):
│ │ │ # ...
│ │ │
Each function marked with this decorator becomes a test │ │ │ case in the current group.
│ │ │The decorator takes one optional argument, the description │ │ │ of the test case: what it should do. If this argument │ │ │ is not provided, the docstring of the decorated function │ │ │ will be used as the test case description.
│ │ │Test functions may optionally take one argument. If they do,
│ │ │ -they will be passed the unittest.TestCase
instance generated
│ │ │ +they will be passed the unittest.TestCase
instance generated
│ │ │ for the test. They can use this TestCase instance to execute assert
│ │ │ methods, among other things.
@it.should('do this')
│ │ │ def dothis(case):
│ │ │ # ....
│ │ │
│ │ │ @it.should
│ │ ├── ./usr/share/doc/python-nose2/html/usage.html
│ │ │ @@ -207,15 +207,15 @@
│ │ │ These files will not be run:
│ │ │ not_a_test.py
│ │ │ myapp_test.py
│ │ │ some_test_file.py
│ │ │
│ │ │
│ │ │ Within test modules, nose2 will load tests from
│ │ │ -unittest.TestCase
subclasses, and from test functions
│ │ │ +unittest.TestCase
subclasses, and from test functions
│ │ │ (functions whose names begin with “test”).
│ │ │
Running Tests¶
│ │ │In the simplest case, go to the directory that includes your project
│ │ │ source and run nose2
there:
nose2