1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
-- 2/3/07
is the selector useful? can it die, if we assume a more directed loading
approach?
The loader is the heart of the discovery system. It should be simple, clear,
and close to unittest's loader whereever possible. The complication comes from
supporting proper fixture setup and teardown when the test name requested is a
or is inside of a dotted module. Say we run like this:
nosetests foo/bar/baz.py
that should look in foo for setup, then baz for setup, but only after
importing the target module (baz) and finding any tests therein. If baz has
tests, then foo.setup runs, bar.setup runs, baz.setup runs, baz's tests run,
then baz.teardown, bar.teardown, foo.teardown.
nosetests w/o argument is identical in meaning to nosetests .
-> loader.loadTestsFromNames(names=[.])
nosetests foo and nosetests -w foo are identical in meaning
-> loader.loadTestsFromNames(names=['foo'])
loadTestsFromName(name, module=None):
if module is None:
module, name = importable module parts of name, the rest
or, name is a dir
if module:
find name within the module
find all tests in that object (could be the module itself)
return a suite
elif dir:
find all the names in the dir that look like test modules
recurse into load tests from names with that name list
loadTestsFromNames(names, module=None):
for name in names:
yield self.suiteClass(self.loadTestsFromName(name, module))
responsibility for proper setup/teardown lies in the runner, or the suite
class?
how do they know the running context?
the loader returns tests wrapped in a Context() closure
the Context() keeps track of what fixtures have been run and what fixtures
need to be run at setup and teardown
setup is easy -- the first test triggers a cascade of setup calls up to the
package level
but how can we know when to run teardowns? the last test in a module, the last
test in a package should trigger the teardowns at that level... it's not clear
how to know what test is the last?
we know what's last because tests for a given package don't start running
until they have all been collected.
the process of
-- old
notes on loading from modules
this pretty much all has to take place inside of the _tests iterator.
if the module is wanted
run setup
load tests (including submodules) and yield each test
run teardown
else if the module is not wanted:
* do not import the module *
if the module is a package:
recurse into the package looking for test modules
make suite.TestSuite
put run, call, setup, teardown, shortdescription there
make LazySuite subclass it
get rid of TestModule
do module import in loadTestsFromModuleName; if an error, pass the error
to the module suite, whose run() should re-raise the error so that import
errors are seen only when we actually try to run the tests
make ModuleSuite class with setUp, tearDown doing try_run, it gets
additional module and error keyword args
rename TestDir to DirectorySuite
try to make things less stateful
- conf should be immutable?
- certainly conf.working_dir shouldn't change, or if it does it has to be a
stack
- things that are mutable should be removed from conf and passed separately
tests and working dir should come out of conf and be passed to loader and
selector
loader.loadTestsFromNames(names, module=None, working_dir=None)
-> split and absolutize all of the test names
-> give them to the selector (self.selector.tests = names)
-> start walking at working_dir
-> sort dirnames into test-last order
-> yield loadFromName for wanted files
-> ModuleSuite
-> for directories:
- keep descending if wanted and not a package
- remove from list if not wanted
- if a package, yield loadFromName for package
-> ModuleSuite
-> since module has a path, we need to restart the walk
and call loadTestsFromNames with the path end as the working dir
but we want to do that lazily, so we need to bundle up the
needed information into a callable and a LazySuite
loader.collectTests(working_dir, names=[]):
-> yield each test suite as found
suites:
ModuleSuite
ClassSuite
TestCaseSuite
GeneratorSuite
GeneratorMethodSuite
*
proxy suite may need to be mixed in by the collector when running under test
or, suite base class has a testProxy property, which if not None is called to
proxy the test
*
module isolation plugin will break under depth-first loading. how to restore
it:
preImport hook
- snapshot sys.modules: this is what to restore AFTER processing of the
test module is complete
postImport hook
- snapshot sys.modules: this is what to restore BEFORE running module tests
startTest
- if isa module, restore postImport sys.modules snapshot
stopTest
- if isa module, restore preImport sys.modules snapshot
|
