111
111
>>> mytests = loader.loadTestsFromNames(['doc.test_sample'])
112
112
>>> test_suite.addTests(generate_scenarios(mytests))
113
113
>>> runner.run(test_suite)
114
<unittest._TextTestResult run=1 errors=0 failures=0>
114
<unittest...TextTestResult run=1 errors=0 failures=0>
264
Some functions (currently one :-) are available to ease generation of scenario
265
lists for common situations.
267
Testing Per Implementation Module
268
+++++++++++++++++++++++++++++++++
270
It is reasonably common to have multiple Python modules that provide the same
271
capabilities and interface, and to want apply the same tests to all of them.
273
In some cases, not all of the statically defined implementations will be able
274
to be used in a particular testing environment. For example, there may be both
275
a C and a pure-Python implementation of a module. You want to test the C
276
module if it can be loaded, but also to have the tests pass if the C module has
279
The ``per_module_scenarios`` function generates a scenario for each named
280
module. The module object of the imported module is set in the supplied
281
attribute name of the resulting scenario.
282
Modules which raise ``ImportError`` during import will have the
283
``sys.exc_info()`` of the exception set instead of the module object. Tests
284
can check for the attribute being a tuple to decide what to do (e.g. to skip).
286
Note that for the test to be valid, all access to the module under test must go
287
through the relevant attribute of the test object. If one of the
288
implementations is also directly imported by the test module or any other,
289
testscenarios will not magically stop it being used.
261
292
Advice on Writing Scenarios
262
293
===========================
added
removed
README
