forked from nose-devs/nose
-
Notifications
You must be signed in to change notification settings - Fork 0
/
tickets.csv
We can make this file beautiful and searchable if this error is corrected: Illegal quoting in line 12.
115 lines (115 loc) · 64.6 KB
/
tickets.csv
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
__color__,__group__,__style__,ticket,summary,component,status,resolution,version,severity,priority,owner,description,modified,_time,_reporter
3,1.0,font-weight: bold,90,Improve logging config options,nose,new,None,,enhancement,normal,jpellerin,Logging (for nose itself and the packages it tests) config should be more accessible -- esp. it should be possible to configure logging with a standard logging config file. Attachment is a plugin from Oliver Rutherfurd that adds --log-config and --log-filename options. This should be adapted and made part of configure_logging in nose.core.,1158168669,1158168669,jpellerin
3,1.0,font-weight: bold,85,Is it possible to have more control over TestProgram configuration when running the nose from within python code?,nose,assigned,None,0.9,enhancement,normal,jpellerin,I am trying to use nose with the NoseXML plugin. When I call: nose.run(argv=['--with-nosexml'_'--xml-report-file=some_file'])_ I get my NoseXML output in some_file. This is nice. On the other hand_ it would be nicer if I could specify a StringIO that the NoseXML could write to instead of a file in the filesystem. I have managed to do this by poking around inside the nose.core.TestProgram class and nose.core.configure function_ but my solution is not really acceptable for long-term use. I manually insert a StringIO into the configuration information after argv is parsed and before it is passed to the plugins. Please consider providing a different means for specifying configuration information to nose when it is run using nose.run(). I would be glad to help with this if it would be an acceptable change. And if I've missed the proper way to do something like this_ please let me know. Thanks_ Matthew Desmarais,1156804579,1156793693,q_canada-at-yahoo.com
3,1.0,font-weight: bold,57,.noserc,nose,assigned,None,1.0,normal,normal,jpellerin,Support reading options from a .noserc file or other config file. Format should be the same as command line args (long form)_ minus the --.,1147630012,1147630001,jpellerin
3,1.0,color: #777; background: #ddd; border-color: #ccc;,80,provide TestCase methods as functions.,nose,closed,worksforme,0.9,enhancement,normal,jpellerin,Hi First of all I'm new to nose and I like what I see_ I always complained about JUnit/pyUnit because it's too much troubles ... nose takes that away from me. but when I try to test for a method that should raises a certain type of exception I found out that the only way to do this is with TestCase_ at least to catch a certain specific type of test. So how abotu adding a reimplementation (basically transform the methods into functions of TestCase.* into module level nose functions? So we can implement this {{{ class TestMyApp(TestCase): def test_create(self): self.failUnlessRaises(NotImplementedError_ source.create) }}} as {{{ def test_create(): nose.failUnlessRaises(NotImplementedError_ source.create) }}} here is the original thread. http://tinyurl.com/mvssg,1154752873,1154742572,jorge.vargas
3,1.0,color: #777; background: #ddd; border-color: #ccc;,24,Allow plugins to completely change test output,nose:plugins,closed,fixed,1.0,normal,normal,jpellerin,Currently watcher plugins can report() to add to test output_ but there should be a hook for plugins to take over and do all test output.,1143522249,1143169945,jpellerin
2,0.9rc1,color: #777; background: #ddd; border-color: #ccc;,27,Missing units,nose,closed,fixed,0.9a1,major,high,jpellerin,Missing unittests for many core functions: * loader testsInModule * loader FunctionTestCase * loader MethodTestCase * LazySuite.run,1151027521,1143519866,jpellerin
3,0.9b1,color: #777; background: #ddd; border-color: #ccc;,61,Attribute plugin 'OR' test doesn't work,nose:plugins,closed,fixed,0.9a1,normal,normal,jpellerin,nosetests -a tags=a -a tags=b should select tests that have a tags attribute with the value of 'a' or 'b' or a list containing one or both of those values_ but it doesn't.,1148515497,1148351284,jpellerin
3,0.9b1,color: #777; background: #ddd; border-color: #ccc;,59,nose.tools.raises hides module of original test,nose,closed,fixed,0.9a1,minor,normal,jpellerin,When using nose.tools.raises_ the test reports look like: {{{ nose.tools.<testfunc> }}} Instead of: {{{ <testmod>.<testfunc> }}} raises needs to set the name or module of the wrapper it returns properly.,1148515476,1147897945,jpellerin
2,0.9b1,color: #777; background: #ddd; border-color: #ccc;,58,ArrtibuteError running nosetests,nose:importer,closed,fixed,0.9a1,normal,high,jpellerin,I'm getting this when running nosetests. Not sure whats causing it_ but I thought someone might be able to point me in the right direction. I will attach the traceback.,1148515456,1147879026,[email protected]
3,0.9a2,color: #777; background: #ddd; border-color: #ccc;,54,ignore all executable files?,nose,closed,fixed,0.9,normal,normal,jpellerin, * Is this desirable? (YES) * Is it possible to do_ dependably_ cross-platform? (YES),1147140636,1146622844,jpellerin
3,0.9a2,color: #777; background: #ddd; border-color: #ccc;,51,nose.collector causes loop when running `setup.py test`,nose,closed,invalid,0.9a1,normal,normal,jpellerin,have a looksee here at my setup.py file: svn co http://svn.testtools.python-hosting.com/trunk --revision=186 testtools I'm using test_suite = "nose.collector" and when I run `setup.py test` with 0.9a1 it gets caught in a loop like so : running test running egg_info writing testtools.egg-info/PKG-INFO writing top-level names to testtools.egg-info/top_level.txt writing manifest file 'testtools.egg-info/SOURCES.txt' running build_ext At revision 186. running test running egg_info writing testtools.egg-info/PKG-INFO writing top-level names to testtools.egg-info/top_level.txt writing manifest file 'testtools.egg-info/SOURCES.txt' running build_ext At revision 186. ... but when I run `nosetests` everything goes smooth. I mentioned in the email that it was working on dev2_ but I meant it was working for other projects. I.E. running `python setup.py test` in etl/trunk/py-lib/ works just fine. I can't see offhand what is different.,1147140543,1146498659,[email protected]
3,0.9a2,color: #777; background: #ddd; border-color: #ccc;,53,plugin import errors kill test run,nose:plugins,closed,fixed,0.9,major,normal,jpellerin,Plugin import errors need to be reduced to warnings_ since the import happens before users have a chance to disable the plugin. Example: If profile module is not installed_ nosetests exits with exception without running any tests.,1147140412,1146507699,jpellerin
3,0.9a2,color: #777; background: #ddd; border-color: #ccc;,52,profile plugin shadows builtin profile module,nose:plugin:profile,closed,fixed,0.9a1,major,normal,jpellerin,It needs a name change_ causes nosetests to fail to load on some platforms.,1147140384,1146507509,jpellerin
3,0.9a2,color: #777; background: #ddd; border-color: #ccc;,56,wantFunction and wantMethod bugs in attr [patch],nose:plugins,closed,fixed,0.9,normal,normal,jpellerin,this might be better fixed in the loader since I think at least for the wantMethod bug_ it should not get something that's not a method. But this patches was necessary to allow a large ETL suite to run that I'm trying to use attributes in. a patch against branches/0.9-stable is to follow,1146939370,1146843133,Kumar McMillan <[email protected]>
3,0.9a2,color: #777; background: #ddd; border-color: #ccc;,55,bug in doctest plugin loadTestsFromPath [patch],nose:plugin:doctest,closed,fixed,0.9a1,normal,normal,jpellerin,we get an iteration error in the doctest plugin when looking at a directory filename (i.e. not a valid .py file). A patch is to follow ...,1146798517,1146669523,[email protected]
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,50,Update mkrelease,nose,closed,fixed,0.9,normal,high,jpellerin,Update mkrelease to make svn/svk branch and tag instead of bzr.,1146441331,1145838610,jpellerin
4,0.9a1,color: #777; background: #ddd; border-color: #ccc;,4,doc -> wiki,nose,closed,fixed,0.9a1,normal,low,jpellerin,Add a script similiar to mkindex.py that posts doc updates to the right places in this wiki.,1146106486,1141872678,jpellerin
1,0.9a1,color: #777; background: #ddd; border-color: #ccc;,49,Update docs for 0.9,nose,closed,fixed,0.9,normal,highest,jpellerin, * Update the CHANGELOG and NEWS files. * Update module_ package and class docstrings * Update TestProgram usage * Update mkindex_ make sure it is pulling all relevant info * Update hacking_ etc_ on index to include new svn repos information * Add to this ticket as I think of more doc updates that are needed,1146106433,1145836661,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,37,setuptools integration phase 2: disable plugins,nose:plugins,closed,fixed,0.9,normal,normal,jpellerin,When run under setuptools_ should disable plugins that implement methods that won't get a chance to run (report_ finalize_ prepareTest_ setOutputStream).,1145935337,1144723989,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,48,logging behavior: ignore root logger settings,nose,closed,fixed,0.9,normal,normal,jpellerin,Since nose is likely to be run in unstable environments where users are setting their root or other loggers to debug to debug their own code_ and those users are probably not interested in nose's debug info_ nose should explicitly override the root logger settings in the 'nose' domain. Don't use basicConfig_ but compose a handler and formatter and set the log level to whatever is appropriate for the selected verbosity level.,1145836506,1145667736,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,46,super?,nose,closed,fixed,0.9,normal,normal,jpellerin,Check usage of super() vs direct __init__ calls. Ref: http://fuhm.net/super-harmful/,1145836488,1145372445,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,44,disable attrib plugin eval option for versions < 2.4,nose:plugins,closed,fixed,0.9,normal,normal,jpellerin,eval() can't take an instance in 2.3_ so the attrib eval() option must be disabled in 2.3.,1145836452,1145329766,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,45,Fix tests for 2.3,nose:selftest,closed,fixed,0.9,normal,normal,jpellerin,Many tests are failing under 2.3 due to incompatibile iteration_ etc.,1145496998,1145330134,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,43,nosetests bad_file.py -> greedy loads,nose,closed,fixed,0.9,normal,normal,jpellerin,When given a bad file name_ nosetests loads tests from all modules instead of issuing a warning.,1145210494,1145160913,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,42,nosetests relative/path.py -> no tests loaded,nose,closed,fixed,0.9,normal,normal,jpellerin,Test name resolution for relative filenames is wrong. The files are not loaded.,1145210478,1145160805,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,41,profiler plugin is broken,nose:plugin:profile,closed,fixed,0.9,normal,normal,jpellerin,Trying to run with profiler enabled results in errors from the hotshot stats loader: {{{ Could not identify fileId 10 Could not identify fileId 10 Traceback (most recent call last): File "<stdin>"_ line 1_ in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/hotshot/stats.py"_ line 12_ in load return StatsLoader(filename).load() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/hotshot/stats.py"_ line 29_ in load for event in log: File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/hotshot/log.py"_ line 120_ in next filename = self._filemap[fileno] KeyError: 91 }}},1145210457,1145160589,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,40,stop on first error,nose,closed,fixed,0.9a1,normal,normal,jpellerin,Suggestion from Kevin Dangoor: Add an option to stop running tests on the first failure.,1145210422,1144937337,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,36,loader.loadTestsFromNames behavior,nose,closed,fixed,0.9,normal,normal,jpellerin,The test loader's loadTestsFromNames behavior isn't compatible with single-test-file unittest-style command lines_ eg: {{{ python unit_tests/test_loader.py TestNoseTestLoader.test_generate_func }}} It needs to be revised for compatibility with unittest.,1145210398,1144543740,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,34,nose.main signature does not match unittest.main,nose,closed,fixed,0.9,normal,normal,jpellerin,nose.main should be usable interchangably with unittest.main.,1145210364,1144377521,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,33,coverage plugin: option to erase before run,nose:plugin:coverage,closed,fixed,0.9,normal,normal,jpellerin,The coverage plugin should have an option to allow the user to erase accumulated stats before a test run.,1144886539,1144035280,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,32,revise setuptools support_ phase 1,nose,closed,fixed,0.9,normal,normal,jpellerin,To support setuptools test command as best as possible without monkeypatching_ follow PJE's prescription: {{{ #!python class ResultProxy: def addError(self_ test_ err): # reformat err_ adding captured info # then calling addError() on the wrapped result def startTest(self_ test): # code to begin output capture and assertion tracking # then call startTest() on the wrapped result def stopTest(self_ test): # code to end output capture and assertion tracking # then call stopTest() on the wrapped result # ... etc. class TestProxy: def __call__(self_ result): self.wrapped_test(ResultProxy(result)) def shortDescription(self): return self.wrapped_test.shortDescription() }}} The test_suite hook is still better than the test_loader hook_ since test suite can be a function that does other setup; it should configure the system with a setting that deactivates any plugins that can't be supported under this scenario (that is_ any plugin that uses report_ finalize_ prepareTest or setOutputStream),1144723915,1143866267,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,31,nose.tools,nose,closed,fixed,0.9,normal,normal,jpellerin,Create nose.tools module and move with_setup there. Also add: * @raises * @timed And try to think of some more useful_ general test-writing tools to add.,1144723893,1143816999,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,14,test generators for methods do not work,nose,closed,fixed,0.8.7.1,normal,normal,jpellerin,Given the following testclass: class TestSomething(object): def setUp(cls): cls.x = 5 print "setting up" def test_1(self): assert self.x == 4 def test_2(self): assert self.x == 6 def test_3(self): for x in (1_2_7): yield self.check_x def check(self_arg): assert arg %7 ==0 Method test_3 does not function as a proper test generator. What should probably happen is: 1) test_3 generates three separate tests_ just like regular test generators 2) Each of the three tests created by test_3 should get setUp() called when they're called.,1144723873,1142702895,guest
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,25,profiler: output controls,nose:plugin:profile,closed,fixed,0.9,normal,normal,jpellerin,Need controls and options for those controls for the profiler plugin. Including: * formatting options -- sort_ restrict func names_ % of list * prof data filename option (file to store profile data in during run) * print/no print report * print to report stream * output to file ,1144378756,1143170571,jpellerin
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,10,document plugin interfaces,nose:plugins,closed,fixed,0.9a1,normal,high,jpellerin,Document the collector_ selector and watcher methods that plugins can implement and where they are called in the process.,1144378682,1142090806,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,22,loading tests from classes: beware subclassing,nose,closed,fixed,0.9,normal,normal,jpellerin,The following case will currently result in wrong behavior: {{{ #!python class TestA: def test_a(self): pass class TestB(TestA): def test_b(self): pass }}} TestB will collect and run both test_a and test_b; it should only run test_a,1144034906,1143162155,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,8,warn on missed test names,nose,closed,fixed,0.9a1,normal,normal,jpellerin,When called with test names on the command line_ eg: {{{ nosetests foo.bar.test }}} nose should track what tests it finds and runs_ and warn at the end if a specified test name was not found. Not sure where to do the tracking.,1144034848,1141916650,jpellerin
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,30,pass captured output to plugins,nose:result,closed,fixed,0.9a1,normal,high,jpellerin,In addError and addFailure_ pass captured output (if any) to plugin calls.,1143690219,1143522347,jpellerin
1,0.9a1,color: #777; background: #ddd; border-color: #ccc;,29,_import failure,nose:importer,closed,fixed,0.9a1,blocker,highest,jpellerin,This import shouldn't be failing in selftest: {{{ ====================================================================== ERROR: test module stpackage.subpak.other.tests in /Users/jhp/projects/nose_work_0.9/st ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/jhp/projects/nose_work_0.9/nose/suite.py"_ line 35_ in run self.setUp() File "/Users/jhp/projects/nose_work_0.9/nose/suite.py"_ line 128_ in setUp self.module = _import(self.moduleName_ [self.path]_ self.conf) File "/Users/jhp/projects/nose_work_0.9/nose/importer.py"_ line 63_ in _import fh_ filename_ desc = find_module(part_ path) ImportError: No module named tests }}},1143690204,1143520279,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,19,watcher plugin API: access to test results,nose:plugins,closed,fixed,0.9a1,normal,normal,jpellerin,make it easier for watcher plugins to access test results... possibly call addError_ etc_ in plugins from TextTestResult.,1143522094,1143041674,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,16,unit tests for plugin option handling,nose,closed,fixed,0.9a1,normal,normal,jpellerin,See #15 for an example of why these are needed. All builtin plugins and builtin options/config need unit tests to ensure that they function as advertised,1143522068,1142723348,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,26,func_names -> funcNames,nose,closed,fixed,0.9a1,minor,normal,jpellerin,Much as I hate camelCase_ unittest uses it and some overridden methods must use it_ so for consistency_ everythingShouldLookLikeThis.,1143434947,1143261806,jpellerin
1,0.9a1,color: #777; background: #ddd; border-color: #ccc;,23,refactor: revise for better unittest compatibility,nose,closed,fixed,1.0,normal,highest,jpellerin,Refactor implemenation for a better fit with the slots provided. Ideas: * LazySuite replaces collector * Move loading from TestCollector_ TestModule_ etc into loader * Loader gets selector * Loader instantiates LazySuites and passes itself to them Add more details to this ticket.,1143434892,1143162697,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,18,setUpModule doesn't work,nose,closed,fixed,0.8.7.1,normal,normal,jpellerin,In the documentation_ it says you can use 'setUpModule' as the setup function for a module. In the code though_ it actually uses 'setupModule' (note the different case on the 'u'),1143173433,1143040353,guest
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,2,implement profiler plugin,nose:plugin:profile,closed,fixed,0.9a1,normal,normal,jpellerin,Plugin should be a Watcher that outputs a profiler report after test run. Possibly exclude test packages from report_ have a --profile-package argument (like coverage plugin).,1143173411,1141872386,jpellerin
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,17,improve library discovery,nose:selector,closed,fixed,0.9a1,normal,high,jpellerin,nosetests deals badly with a common package layout: {{{ pack lib foo.py test test_foo.py }}} To be friendlier to that layout_ selector should be updated to want directories that look like common source directories (lib and src at least). ,1143173374,1142889537,jpellerin
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,5,'EOF in multiline input',nose:assert,closed,fixed,0.9a1,normal,high,jpellerin,Assert introspection fails for many expressions with an error like 'EOF in multiline input',1142808065,1141873478,jpellerin
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,15,attrib plugin env defaults should not be strings,nose:plugins,closed,fixed,0.9a1,major,high,jpellerin,The attrib plugin is currently broken because the option defaults are strings_ but the option type is append.,1142808025,1142723250,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,9,use logging for messaging,nose,closed,fixed,0.9a1,normal,normal,jpellerin,This will be a 2-step process: 1. replace nose.util.msg() with real logging_ using the builting logging module. 2. provide an interface for selecting which loggers and levels to output and where ,1142483305,1142090654,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,7,add option to activate pdb on error/fail,nose,closed,fixed,0.9a1,normal,normal,jpellerin,Add command line option/env var to activate the pdb on error/fail feature.,1142483270,1141875053,jpellerin
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,6,patch AssertionError only,nose,closed,invalid,0.9a1,normal,high,jpellerin,Install the patch that introspects assets as AssertionError only_ instead of patching builtin.Exception.,1142397435,1141873541,jpellerin
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,12,patch: attribute-based test case selector,nose,closed,fixed,0.9a1,normal,normal,jpellerin,This patch adds selecting test cases based on their attributes. Examples of test function/method attribute usage with patched nose Simple syntax (-a_ --attr) examples: * nosetests -a status=stable => only test cases with attribute "status" having value "stable" * nosetests -a priority=2_status=stable => both attributes must match * nosetests -a tags=http => attribute list "tags" must contain value "http" (see test_foobar() below for definition) * nosetests -a slow => attribute "slow" must be defined and its value cannot equal to False (False_ []_ ""_ etc...) * nosetests -a !slow => attribute "slow" must NOT be defined or its value must be equal to False Eval expression syntax (-A_ --eval-attr) examples: * nosetests -A "not slow" * nosetests -A "(priority > 5) and not slow" This example and the accompanied patch is in public domain_ free for any use. ,1142397373,1142193709,guest
3,0.9a1,color: #777; background: #ddd; border-color: #ccc;,11,patch: Windows path handling issues,nose,closed,fixed,0.9a1,normal,normal,jpellerin,Nose 0.9 r5 fails to run any test cases on Windows. Here's a patch with fixes to some path handling issues. - Mika ,1142179440,1142162540,guest
2,0.9a1,color: #777; background: #ddd; border-color: #ccc;,3,use clean config in units,nose:selftest,closed,fixed,0.9a1,normal,high,jpellerin,In the unittests in selftest_ each class or instance that can take a config argument should get a fresh _Config()_ so that the configuration of the driving test runner doesn't leak into the test cases.,1142092735,1141872555,jpellerin
3,0.9.2,font-weight: bold,113,python setup.py nosetests --stop was raise TypeError,nose,assigned,None,0.9,normal,normal,jpellerin,I'm not sure if this would be true across all extra options sent to setup.py nosetests_ however the fix seemed simple enough (the internals needed to handle integer values). A rough patch is following (this got it working). All this_ using nose revision 143 and setuptools 0.6c3,1166026105,1165886115,kumar dot mcmillan / gmail
3,0.9.2,font-weight: bold,110,isolation plugin,nose:plugins,assigned,None,,enhancement,normal,jpellerin,Include a plugin in core that resets the state of sys.modules between after each test module is run.,1165080721,1165080713,jpellerin
3,0.9.2,font-weight: bold,109,doctest vs coverage,nose:plugin:doctest,assigned,None,,normal,normal,jpellerin,doctest requires a patch (or monkeypatch) to work correctly with the coverage module. ref: http://www.nedbatchelder.com/code/modules/coverage.html http://svn.zope.org/Zope3/trunk/src/zope/testing/doctest.py?rev=28679&r1=28703&r2=28705 Since nose can't patch a user's doctest directly_ we'll have to monkeypatch in a revise _OutputRedirectingPdb.,1165003349,1165003342,jpellerin
3,0.9.2,font-weight: bold,108,Generate and post plugin docs,nose:plugins,assigned,None,,normal,normal,jpellerin,Generate HTML docs for built-in plugins and post them to the site and wiki.,1164209462,1164209456,jpellerin
3,0.9.2,font-weight: bold,106,Revise long description in setup.py,nose,assigned,None,,normal,normal,jpellerin,Revise the long description in setup.py to be more accurate and descriptive.,1164124115,1164124107,jpellerin
3,0.9.2,font-weight: bold,100,nosetests man page,nose,assigned,None,,enhancement,normal,jpellerin,Install a man page for nosetests on install. A man page contributed by Gustavo Noronha Silva is attached to this ticket.,1162073265,1162073165,jpellerin
4,0.9.2,font-weight: bold,112,test can't be run from package directory -- misleading INFO message,nose,assigned,None,,normal,low,jpellerin,I have a small module_ i.e. a dir (say_ package/) which has an __init__.py_ a foo.py and a test_foo.py test_foo.py has the line 'import foo' in it_ as it contains the test code for the code in foo.py I try to run the tests by running 'nosetests -vv' in the dir. I see the line "nose.core: INFO: Working directory is a package; adding to sys.path" appear_ but the tests won't run_ I get an ImportError: No module named foo The problem is that the message "Working directory is a package; adding to sys.path" is misleading. I doesn't add the current directory_ it adds the _parent_ of the current directory to sys.path. (Due to the way add_path() is implemented in sys.path) I'm not sure how to characterise this problem. Simply having 'import package.foo' instead of 'import foo' in test_foo.py makes it work. Is there any reason to prohibit using 'import foo' in this case? Or maybe using add_path() for adding the current working directory is a bug? ,1166026048,1165855566,guest
4,0.9.2,font-weight: bold,102,Nose frontpage installation instructions in error,nose,assigned,None,0.9.1,minor,low,jpellerin,These instructions are wrong: {{{ Install nose using setuptools: easy_install nose Or_ if you don't have setuptools installed_ use the download link at right to download the source package_ and install in the normal fashion: Ungzip and untar the source package_ cd to the new directory_ and: python setup.py install }}} You cannot run python setup.py install without setup_tools upgraded to at least the version that nose is configured to work with_ as per this error message: {{{ $ sudo python setup.py install ~/src/nose-0.9.1 The required version of setuptools (>=0.6c2) is not available_ and can't be installed while this script is running. Please install a more recent version first. (Currently using setuptools 0.6c1 (/usr/lib/python2.4/site-packages/setuptools-0.6c1-py2.4.egg)) zsh: 32149 exit 2 sudo python setup.py install }}} I recommend ammending the instructions to say {{{ python ez_setup.py python setup.py install }}} and note that the installation will cause easy_install to be installed. Perhaps a link to ez_setup.py would be good too.,1162913345,1162769184,[email protected]
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,95,evaluating asserts stops working when there is a two-line docstring,nose,closed,fixed,0.9,normal,normal,jpellerin,This is a problem with nose version 0.9.0. When I run the following test with nosetests -d option_ def test_integers(): a = 2 assert a == 4 I get this expected result_ the variable a is expanded: ... assert a == 4 AssertionError 2 = 2 >> assert 2 == 4 However_ when I add a two-line docstring like that: def test_integers(): """docstring line 1 docstring line 2 """ a = 2 assert a == 4 then_ instead of the variable expansion_ the last line of the docstring is displayed: ... assert a == 4 AssertionError docstring line 2,1165448121,1159996887,[email protected]
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,101,Doesn't select decorated methods/functions,nose:selector,closed,invalid,0.9,normal,normal,jpellerin,If a function has a decoration nose will not pick it up for testing_ it is of type 'function proxy' instead of 'function'. This was tested on Debian testing with version 0.9.0-1 Test case: {{{ def my_decor(func): return lambda: func() def test_decor(): assert False @my_decor def test_decor1(): assert False }}} In the above test case we have two functions_ one decorated and one not. Running it through nosetests shows only one detected function which fails while we expect two functions failing. Running it in verbose mode will show that test_decor1 is not picked up for testing.,1165359172,1162414927,guest
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,111,nosetests -vvvv produces little output,nose,closed,fixed,,minor,normal,jpellerin,You get more output with -v_ -vv_ and -vvv -- but with -vvvv the output goes away,1165358579,1165343732,[email protected]
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,105,nose 0.9.1 does not run functional tests in order of appearance in the module,nose:collector,closed,fixed,0.9.1,normal,normal,jpellerin,In nose main page_ http://somethingaboutorange.com/mrl/projects/nose/_ the section titled **Writing tests** says: [quote] Like py.test_ functional tests will be run in the order in which they appear in the module file. TestCase derived tests and other test classes are run in alphabetical order. [endquote] nose 0.9.1 does not seem to do this at all. It seems that it performs the tests in the following order: - run test functions that are defined with the raises decorator - runs the other test functions in alphabetical order of the test function names py.test does run the test functions in order of appearance in the module and I'd like to be able to depend on that when using nose. ,1165357838,1163710775,[email protected]
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,79,ability to change the regex pattern ,nose,closed,fixed,0.9,enhancement,normal,jpellerin,hello_ i just started using nose and i've read the help but can't find a setting to customize the discovery regex. was hoping it would discover tests named with our standard naming system: something like 'modulename_unittest.py'. could this functionality be added?,1165355366,1154476080,guest
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,107,Expose the guts of @raises as assert_raises,nose,closed,fixed,,enhancement,normal,jpellerin,@raises is useful for some users_ but others want to be able to stack up several raises tests inside of one test case_ so it would be helpful to have an assert_raises that they can call directly.,1165354930,1164208688,jpellerin
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,39,setuptools integration: pick up options from setup.cfg,nose,closed,fixed,0.9,normal,normal,jpellerin,Suggestion from Kevin Dangoor: {{{ Even if hooking into setuptools' test command doesn't work_ would it be possible for you to make a distutils command wrapper (setuptools allows you to easily plug in new commands). The reason I say this is that nosetests has a growing set of options_ and it would be nice to be able to specify the right set of options in setup.cfg. }}} First need to figure out what this will require and from that decide the appropriate milestone.,1163907814,1144937275,jpellerin
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,38,setuptools integration phase 3: custom command,nose,closed,fixed,0.9,normal,normal,jpellerin,Create a setuptools command that exposes the full functionality of nose and all plugins.,1163907793,1144724045,jpellerin
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,99,integrated twisted with nose,nose,closed,fixed,,enhancement,normal,jpellerin,Here is the Twisted integration source code. twistedtools.py is the implementation itself (I first tried to call it "twisted"_ but then it shadows the original twisted package). It allows to decorate tests that return a Deferred. test_twisted.py is the test suite for the implementation. There probably should be a way to skip it if Twisted is not installed (instead of raising ImportError all around)_ but I don't know the right way to do that. ,1163385473,1161798402,guest
3,0.9.2,color: #777; background: #ddd; border-color: #ccc;,92,@with_setup doesn't mix well with @raises,nose,closed,fixed,0.9,major,normal,jpellerin,Hi_ I tried to write the following code: @raises(NotEnoughBytes) @with_setup(setup1) def test32(): ... This failed in a strange way. It seems nose either called the wrong setup function (I have different setup functions for different tests)_ or didn't call one at all (I didn't investigate very far). The fix came by inverting the decorator order: @with_setup(setup1) @raises(NotEnoughBytes) def test32(): ... ,1163385442,1159199576,guest
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,98,@with_setup not calling teardown() if test raises exception,nose,closed,worksforme,0.9.1,normal,normal,jpellerin,I'm not sure if this is desired behvior or not_ but I noticed that if a test function decorated with @with_setup() raises an exception then the teardown() method is not called. My personal choice is that a teardown function is called in a finally block as the test is run_ to *always* undo what was done by setup. I took a [very] quick stab at adding a test to nose's suite for this but couldn't come up with one since setup and teardown are just properties set on the test method. hmm. Was using revision 98. -Kumar McMillan,1161544724,1160681294,[email protected]
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,94,--doctest-extension and NOSE_DOCTEST_EXTENSION conflict,nose,closed,fixed,0.9,normal,normal,jpellerin,If you define both the environmental variable and give the command-line variable_ you get: {{{ Traceback (most recent call last): File "/usr/local/bin/nosetests"_ line 7_ in ? sys.exit( File "/usr/local/lib/python2.4/site-packages/nose-0.9.0-py2.4.egg/nose/core.py"_ line 438_ in main return sys.exit(not run(*arg_ **kw)) File "/usr/local/lib/python2.4/site-packages/nose-0.9.0-py2.4.egg/nose/core.py"_ line 446_ in run result = TestProgram(*arg_ **kw).success File "/usr/local/lib/python2.4/site-packages/nose-0.9.0-py2.4.egg/nose/core.py"_ line 199_ in __init__ self.parseArgs(argv_ env) File "/usr/local/lib/python2.4/site-packages/nose-0.9.0-py2.4.egg/nose/core.py"_ line 206_ in parseArgs self.conf = configure(argv_ env) File "/usr/local/lib/python2.4/site-packages/nose-0.9.0-py2.4.egg/nose/core.py"_ line 322_ in configure options_ args = parser.parse_args(argv) File "/usr/lib/python2.4/optparse.py"_ line 1278_ in parse_args stop = self._process_args(largs_ rargs_ values) File "/usr/lib/python2.4/optparse.py"_ line 1318_ in _process_args self._process_long_opt(rargs_ values) File "/usr/lib/python2.4/optparse.py"_ line 1393_ in _process_long_opt option.process(opt_ value_ values_ self) File "/usr/lib/python2.4/optparse.py"_ line 710_ in process return self.take_action( File "/usr/lib/python2.4/optparse.py"_ line 723_ in take_action values.ensure_value(dest_ []).append(value) AttributeError: 'str' object has no attribute 'append' }}},1160517146,1159410819,[email protected]
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,93,try:except: around inspect.getargspec,nose,closed,fixed,,normal,normal,jpellerin,I got this exception from the collector: {{{ File "/usr/local/lib/python2.4/site-packages/nose-0.9.0-py2.4.egg/nose/util.py"_ line 163_ in try_run args_ varargs_ varkw_ defaults = inspect.getargspec(func) File "/usr/lib/python2.4/inspect.py"_ line 670_ in getargspec raise TypeError('arg is not a Python function') }}} nose should catch this and tell more about what "func" really is.,1160517077,1159402148,[email protected]
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,96,Names of modules in test packages ,nose,closed,worksforme,,minor,normal,jpellerin,Test packages are not documented very well. It seems all modules living in a test package are automatically considered test modules_ irrespective whether their names match the testMatch regular expression or not. Is this by design? At least it should be documented.,1160517012,1160000430,guest
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,91,python 2.5: assert introspection: different line counts,nose:assert,closed,fixed,0.9.1,minor,normal,jpellerin,In python 2.5_ some assert introspection tests fail because the traceback source analyzer comes back with different line numbers sometimes than it does in 2.4.,1158692189,1158686657,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,76,No handlers for logger spam,nose,closed,fixed,0.9.1,minor,normal,jpellerin,No handlers could be found for logger "nose.plugins" is spammed to the console sometimes(?) on startup.,1157561941,1153497636,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,86,python version detection broken for 3.0 and above,nose:plugins,closed,fixed,0.9.1,minor,normal,jpellerin,From Kevin Dangoor: {{{ in nose/plugins/attrib.py: compat_24 = pyvrs[0] >= 2 and pyvrs[1] >= 4 would fail with Python 3.0 (though all bets are off for compatibility there anyhow :) Python version detection actually had a discussion on the tg list a few months back. you can rewrite this: compat_24 = sys.version_info >= (2_ 4) }}},1157560233,1157033334,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,81,/lib -style package organization broken,nose,closed,fixed,0.9.1,normal,normal,jpellerin,When a package is organized like: {{{ /lib module.py /tests test_module.py }}} nose loads test_module but even though it has already seen lib_ it has failed to put it on sys.path_ unless a plugin has asked to load all modules. Possible solution: when addPaths is on_ always add the surrounding directory of any .py file we see. ,1156471920,1155046975,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,83,-x/--stop stops on skipped tests,nose,closed,fixed,0.9,normal,normal,jpellerin,the -x/--stop option will stop on a skipped test even though that's not really an error. I haven't tested the others like deprecated tests. Tested w/ version 0.9.0 only.,1156465750,1156456277,kumar mcmillan <[email protected]>
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,75,Multiple --include arguments should 'OR' not override,nose:selector,closed,fixed,0.9.1,normal,normal,jpellerin,Multiple --include arguments should result in everything that matches any of them being included_ instead of the current behavior_ which is that only the last --include issued is used.,1156361851,1153497496,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,78,option for coverage to include all .py files,nose,closed,fixed,0.9,enhancement,normal,jpellerin,Coverage reported by the coverage plugin can be misleading. Files not imported by the test suite will not be reported_ thereby making the coverage appear larger. This patch adds a --cover-inclusive option that will cause all .py files (matching --cover-package if existing) under the working directory to be included in the report.,1155046277,1154185738,James Casbon ([email protected])
2,0.9.1,color: #777; background: #ddd; border-color: #ccc;,72,package.mod:Class doesn't select all tests in class,nose:selector,closed,fixed,0.9,normal,high,jpellerin,It looks like package.mod:Class is broken; it doesn't select all of the tests in the class -- it selects nothing.,1154122686,1152203791,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,74,Possible bug in subpackage_of,nose:selector,closed,fixed,0.9,normal,normal,jpellerin,I was using 0.9b2 earlier without problems_ but after upgrade to 0.9 "python setup.py test" command doesn't work anymore. My directory structure is (full avaiable here: http://pycheesecake.org/browser/branches/mk): {{{ cheesecake/ ... README setup.py tests/ unit/ functional/ data/ }}} Running "nosetests --with-doctest --doctest-tests --include unit --verbose" runs all of the tests in "tests/unit" along with doctests found in package code. But using nose.collector by setup.py script runs only one doctest from the "tests/unit/" directory (so it omits all unit tests and doctests in project directory "cheesecake/"). Our setup.py config is avaiable here: http://pycheesecake.org/browser/branches/mk/setup.py . By browsing through the diff of 0.9b->0.9.0 I've found out that part of code that makes a difference is inside new subpackage_of() function. If you omit comparisons of "mod_parts" and "pkg_parts" (lines 369-379) nose.collector works just like in 0.9b running all of my unit and doc tests.,1153497668,1153338646,[email protected]
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,60,Add function that works like unittest.main(): collects tests in __main__ only,nose,closed,fixed,0.9.1,normal,normal,jpellerin,Add a function to core that works like unittest.main_ that is_ collects test in main only. Usage would be like: {{{ #!python import nose def test_a(): pass def test_b(): pass if __name__ == '__main__': nose.runtests() }}} ,1152755792,1147900584,jpellerin
3,0.9.1,color: #777; background: #ddd; border-color: #ccc;,62,Allow multiple -w arguments,nose,closed,fixed,0.9.1,normal,normal,jpellerin,nosetests should allow multiple -w arguments to include multiple test roots in one run.,1152753796,1148516107,jpellerin
1,0.9.1,color: #777; background: #ddd; border-color: #ccc;,73,nose.collector not finding all tests in `setup.py test`,nose,closed,fixed,0.9,critical,highest,jpellerin,using nose-0.9.0-py2.4.egg ... I'm getting some strange behavior trying to run `python setup.py test` It only finds my doctests. However_ if I run `nosetests -v --with-doctest --doctest-tests` all tests are found. In setup.py I am setting the env vars which would be the equivalent of the above command line options_ i.e. {{{ os.environ['NOSE_WITH_DOCTEST'] = '1' os.environ['NOSE_DOCTEST_TESTS'] = '1' }}} I will dig around the code a little more to see if I can figure out where it's going wrong_ but wanted to submit this ticket in the meantime since you might know where to look in nose.collector here is how to reproduce : {{{ svn co --revision 197 http://svn.testtools.python-hosting.com/trunk testtools cd testtools python setup.py test }}} and this is what I was expecting : {{{ nosetests -v --with-doctest --doctest-tests }}} am I missing anything?,1152716057,1152223849,[email protected]
3,0.9,color: #777; background: #ddd; border-color: #ccc;,71,nosetests -s results in IOError: [Errno 29] Illegal seek,nose,closed,worksforme,0.9,normal,normal,jpellerin,I do: {{{ $ nosetests -s }}} and get: {{{ Traceback (most recent call last): File "/usr/bin/nosetests"_ line 7_ in ? sys.exit( File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/core.py"_ line 434_ in main return sys.exit(not run(*arg_ **kw)) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/core.py"_ line 442_ in run result = TestProgram(*arg_ **kw).success File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/core.py"_ line 201_ in __init__ self.runTests() File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/core.py"_ line 229_ in runTests result = self.testRunner.run(self.test) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/core.py"_ line 100_ in run result = unittest.TextTestRunner.run(self_ test) File "/usr/lib/python2.4/unittest.py"_ line 696_ in run test(result) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 40_ in __call__ self.run(*arg_ **kw) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 54_ in run test(result) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 40_ in __call__ self.run(*arg_ **kw) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 54_ in run test(result) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 40_ in __call__ self.run(*arg_ **kw) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 54_ in run test(result) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 40_ in __call__ self.run(*arg_ **kw) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 54_ in run test(result) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 40_ in __call__ self.run(*arg_ **kw) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/suite.py"_ line 54_ in run test(result) File "/usr/lib/python2.4/unittest.py"_ line 281_ in __call__ return self.run(*args_ **kwds) File "/usr/lib/python2.4/unittest.py"_ line 276_ in run if ok: result.addSuccess(self) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/result.py"_ line 176_ in addSuccess Result.addSuccess(self_ test) File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/result.py"_ line 83_ in addSuccess self.resetBuffer() File "/usr/lib/python2.4/site-packages/nose-0.9.1.dev_r63-py2.4.egg/nose/result.py"_ line 104_ in resetBuffer sys.stdout.truncate(0) IOError: [Errno 29] Illegal seek }}} using nose patch 68 from SVN under Ubuntu Dapper (6.06). Not sure why the egg is labeled dev_r63_ but it's definiately patch 68. ,1151775330,1151499339,guest
3,0.9,color: #777; background: #ddd; border-color: #ccc;,70,Missing file warning spam,nose:selector,closed,fixed,0.9,normal,normal,jpellerin,The missing file warning repeats once for every test file compared against a requested missing file. It would be better to output only once per run per missing file.,1151720295,1151071138,jpellerin
3,0.9,color: #777; background: #ddd; border-color: #ccc;,69,All python files are executable on windows,nose,closed,fixed,0.9,normal,normal,jpellerin,On Windows (or at least my version of Windows XP) all newly created .py files are executable. That is_ os.access(myFilePath_ os.X_OK) returns True for all of my .py files. This means that the default behaviour of omitting executable files unless --exe is set causes doctests in non-test modules to not run on Windows. This happens because non-test modules get checked with wantFile() rather than wantModule() and get ignored becuase there are executable. This bug is hidden slightly at the moment because the sense of --exe is currently reversed - see #68. Currently the doctests are omitted when --exe is used. After #68 is fixed they will be omitted when --exe is ''not'' used. ,1151720276,1150107090,[email protected]
3,0.9,color: #777; background: #ddd; border-color: #ccc;,21,add unittests for lunatic objects,nose:selector,closed,fixed,0.9,normal,normal,jpellerin,Add unittests for weirdo calls that might come up_ such as calling want_function() with something that doesn't have a {{{__name__}}}.,1151028415,1143081832,jpellerin
3,0.9,color: #777; background: #ddd; border-color: #ccc;,1,coverage output for single tests,nose:plugin:coverage,closed,fixed,0.9,normal,normal,jpellerin,Ran: {{{ python nose/core.py -vvvvv -w st/unit_tests --with-coverage --cover-package=nose test_selector }}} Expected: coverage output Actual: no coverage output,1150943529,1141872205,jpellerin
3,0.9,color: #777; background: #ddd; border-color: #ccc;,68,The meaning of '--exe' is backwards,nose:selector,closed,fixed,0.9,normal,normal,jpellerin,the command line option '--exe' is documented as causing more files to be included. Therefore it should '''increase''' the number of tests run. In my tests adding this option actually decreases the number of tests run. {{{ C:\data\code\aa\Newman\POS\gui>python "c:\Program Files\Python23\Scripts\nosetes ts-script.py" -d --with-doctest --doctest-tests -v doctest of DialogExceptHook.DialogExceptHook ... ok ---------------------------------------------------------------------- Ran 1 test in 0.359s OK C:\data\code\aa\Newman\POS\gui>python "c:\Program Files\Python23\Scripts\nosetes ts-script.py" -d --with-doctest --doctest-tests -v --exe ---------------------------------------------------------------------- Ran 0 tests in 0.015s OK }}} I think I've tracked this down to the following code starting on line 241 of source:branches/0.9-stable/nose/selector.py#40 {{{ #!python if not self.conf.ignoreExe and os.access(file_ os.X_OK): log.info('%s is executable; skipped'_ file) return False }}} that 'not' looks like it should not be there. ,1150943322,1150105257,[email protected]
2,0.9,color: #777; background: #ddd; border-color: #ccc;,66,specifying test names causes repeat imports,nose:importer,closed,fixed,,major,high,jpellerin,Specifying test names can change nose's behavior in extremely strange ways. For The attached test case_ the following all produce different import behavior_ in some cases resulting in repeat imports of modules in sys.modules: {{{ nosetests -w zz nosetests nosetests test_model nosetests -w zz test_model }}},1150942667,1149777393,jpellerin
3,0.9,color: #777; background: #ddd; border-color: #ccc;,63,TypeError: iteration over non-sequence,nose:plugin:doctest,closed,fixed,0.9,blocker,normal,jpellerin,This exception is thrown when running: {{{ nosetests --with-doctest . }}} And it's thrown by trying to iterate over the result of DocTest.py::loadTestsFromPath()_ which returns None. My expectation (although I've only read the code diagonally)_ is for loadTestsFromModule() to find my doctests_ and loadTestsFromPath() to be used for loading doctests from other places. I really haven't understood the purpose of loadTestsFromPath()_ have I? I'll attach a patch right away_ but I'm afraid I'm only masking the error somehow; please do look it over to see if that is what's correct.,1150942371,1149021094,[email protected]
3,0.9,color: #777; background: #ddd; border-color: #ccc;,35,profiler: output to stream or file,nose:plugin:profile,closed,fixed,0.9,normal,normal,jpellerin,The profiler plugin should be able to output to the results stream or a selected file.,1145210384,1144380238,jpellerin
2,0.9,color: #777; background: #ddd; border-color: #ccc;,28,Missing units,nose,closed,duplicate,0.9a1,major,high,jpellerin,Missing unittests for many core functions: * loader testsInModule * loader FunctionTestCase * loader MethodTestCase * LazySuite.run,1143521867,1143519867,jpellerin
1,0.10,font-weight: bold,104,rewrite test loading/importing/suites to be easier to follow,nose,assigned,None,0.9.1,normal,highest,jpellerin,The code for test loading_ suites and imports is convoluted and difficult to follow. It should be simplified and clarified.,1163785969,1163457944,jpellerin
2,0.10,font-weight: bold,103,Run fictures (setup/teardown) only for modules or packages that contain tests,nose,reopened,,0.9.1,major,high,jpellerin,my directory structure: {{{ proj/module1/__init__.py(has setup/teardown) module1.py proj/module2/__init__.py(has setup/teardown) module2.py }}} When I run below in proj dir: nosetests module1 -vv I found although only module1.py is running but both module1 package setup/teardown and module2's has run. that means I have to run: nosetests module1 -e module2 to exclude module2. is there a way to run module1 package's test only? I know I could run `nosetest -w module1`_ but this way can't call package setup/teardown. ,1165436116,1163345588,guest
3,0.10,font-weight: bold,89,would like common interface for all test wrapper objects,nose,assigned,None,,enhancement,normal,jpellerin,It would be convenient/efficient/and future-safe to access all of nose's internal test wrappers with a common interface. That is_ convenient for the nose-watch plugin ;) Here is an initial idea_ open to suggestions. I should point out that these are the only things that nose-watch needs to access_ so a complete interface might want more. * wrapper.getTestObject() * the actual test (i.e. !FunctionTestCase.testFunc or !TestModule.module or unittest.!TestCase._'_class_'_) * wrapper.getTestFile() * this one has proven itself really tricky and maybe nose has a better way to do it since it is already looking for tests in the filesystem. Currently I am working around unloadable modules by overloading the load_source() method in ihooks.Hooks. There is also a big problem that I'm not sure is solvable in aliased modules (i.e. "from main import foo" when when foo.py exists in main/foo/foo.py_ concealed by main/foo/__init__.py). I think inspect.getfile() is the one to blame for that_ but I haven't looked into it too far other than knowing it's not working how I would like it. * wrapper.getTestAddress() * get a string "address" of a test. That is_ a name that could be put on the command line of a nosetests call to run this test again. I'm thinking that any unittest.!TestCase method could only return the filename of its module? We should talk before you start work on this ... or perhaps I will just add a patch or two to this ticket if I get around to it first. I'll wait until 0.9.1 is out the door.,1164123000,1158004717,kumar mcmillan <[email protected]>
3,0.10,font-weight: bold,84,Generator tests with mutable arguments = bad,nose,assigned,None,,normal,normal,jpellerin,From Kevin Dangoor: {{{ A coworker found an interesting bug in test generators. Apparently_ py.test does the same thing. Maybe this is architecturally difficult to contend with. Here's the test: #! /usr/bin/env python def test_list_loop(): def check_list_loop(ls_ len_expected): print ls assert len(ls) == len_expected ls = list() for i in range(0_ 6): ls.append(i) yield check_list_loop_ ls_ i + 1 It appears that each yielded test is not run immediately_ but is collected up and *then* run. In this particular case_ that fails because a mutable object is involved (and mutated as part of the test running). Changing that last line to yield check_list_loop_ ls[:]_ i + 1 makes it work_ because you're dealing with copies of the list each time. }}},1164123047,1156525484,jpellerin
2,,font-weight: bold,13,update selftest.py,nose:selftest,assigned,None,,normal,high,jpellerin,Update selftest to account for the new tests in units and unit support.,1151019152,1142483367,jpellerin
3,,font-weight: bold,114,nosetests 0.9.1 leaks 0-byte temporary files under Windows,nose,new,None,0.9.1,normal,normal,jpellerin,I just noticed that nosetests 0.9.1 creates and leaves behind one temporary file each time it executes_ running a test. Under Windows_ the file are left in C:\Windows\Temp and have names similar to tmpxxxxx. It is probably a file name created by tempfile module function somewhere. These files should be deleted when nosetests terminates. I am not running any plugins. The test is very simple. Even an empty test creates a temp file leak. ,1166407315,1166407315,guest
3,,font-weight: bold,47,optimize startup time for lib/ test/ and package/ test/ cases,nose,assigned,None,,normal,normal,jpellerin,Startup time for layouts like: - lib/ - test/ Or: - package/ - test/ Is very bad_ since nose examines everyting in package/ and lib/ before looking in test/. This should be fixable_ since it's only looking in the libs first to be sure that their root dirs are in sys.path before the tests are loaded.,1151019121,1145372575,jpellerin
3,,color: #777; background: #ddd; border-color: #ccc;,97,@with_setup not calling teardown() if test raises exception,nose,closed,duplicate,0.9.1,normal,normal,jpellerin,I'm not sure if this is desired behvior or not_ but I noticed that if a test function decorated with @with_setup() raises an exception then the teardown() method is not called. My personal choice is that a teardown function is called in a finally block as the test is run_ to *always* undo what was done by setup. I took a [very] quick stab at adding a test to nose's suite for this but couldn't come up with one since setup and teardown are just properties set on the test method. hmm. Was using revision 98. -Kumar McMillan,1161534207,1160681280,guest
3,,color: #777; background: #ddd; border-color: #ccc;,87,nose-django fails for apps with no models.py,nose:plugins,closed,fixed,,normal,normal,jpellerin,nose-django fails at nosedjango.py line 141_ for any app which has no models.py (e.g. django/contrib/markup) Since it's not required to have a models.py file in every app_ should begin() protect itself_ e.g. only run management.install where load_app(app) is not None ? or you could say it's a fault in django. a blank models.py fixes it. ,1157559960,1157443138,guest
3,,color: #777; background: #ddd; border-color: #ccc;,88,call to debug log raises IndexError,nose,closed,fixed,0.9.1,normal,normal,jpellerin,some straggler debug code from a condition yet to be evaluated is raising an IndexError. This is in selector.py_ revision 94. Here is a patch.,1157559860,1157468103,Kumar McMillan <[email protected]>
3,,color: #777; background: #ddd; border-color: #ccc;,82,NameError in class def *only* when running nosetests,nose,closed,invalid,0.9.1,normal,normal,jpellerin,I could be missing something obvious_ but this has me completely stumped. I figure you know more about the environment that nose imports code into so_ I dunno_ take a look and let me know what you think. Try this: {{{ svn co --revision=238 http://svn.testtools.python-hosting.com/trunk/ testtools_238 cd testtools_238 nosetests -v testtools/testself/test_fixtures/test_storable.py }}} all tests should pass. now_ open up testtools/testself/test_fixtures/test_storable.py and edit a few things : * change mknewfile2 on line 241 to mknewfile * change mknewfile2 on line 249 to mknewfile now run it again and you should get : {{{ Traceback (most recent call last): File "/Users/kumar/tmp/tt_nose_flop/testtools/testtools/testself/test_fixtures/test_storable.py"_ line 246_ in test_mknewfile class MyAutoCsv(CsvFixture): File "/Users/kumar/tmp/tt_nose_flop/testtools/testtools/testself/test_fixtures/test_storable.py"_ line 247_ in MyAutoCsv class meta: File "/Users/kumar/tmp/tt_nose_flop/testtools/testtools/testself/test_fixtures/test_storable.py"_ line 249_ in meta mknewfile = mknewfile NameError: name 'mknewfile' is not defined }}} now ... to make sure we're all sane_ shouldn't the exact same error happen when we simply compile the code? {{{ python testtools/testself/test_fixtures/test_storable.py }}} Yet it does not. In addition_ I have tried to reproduce a similar NameError in the python shell without success. And I've also tried taking that test function out of the unittest.TestCase class so that it is a standalone def_ it still failed. I guess it's some kind of referencing issue but I can't think of any reason why this could happen *only* in nose. - kumar,1156464833,1155846492,guest
3,,color: #777; background: #ddd; border-color: #ccc;,77,Importer bug for modules starting with underscore,nose:importer,closed,invalid,0.9.1,normal,normal,jpellerin,I will paste the session dump that presents the issue here. Files needed to reproduce this in attachement. {{{ $ nosetests --verbose --include \(unit\)\|\(functional\) No handlers could be found for logger "nose.plugins" test_from_functional.TestFunctional.test_functional ... ok ERROR ====================================================================== ERROR: test module test_from_unit in /tmp/blah/tests/unit ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/nose-0.9.1.dev_r77-py2.3.egg/nose/suite.py"_ line 44_ in run self.setUp() File "/usr/lib/python2.3/site-packages/nose-0.9.1.dev_r77-py2.3.egg/nose/suite.py"_ line 187_ in setUp self.module = _import(self.moduleName_ [self.path]_ self.conf) File "/usr/lib/python2.3/site-packages/nose-0.9.1.dev_r77-py2.3.egg/nose/importer.py"_ line 96_ in _import mod = load_module(fqname_ fh_ filename_ desc) File "/tmp/blah/tests/unit/test_from_unit.py"_ line 1_ in ? from _helper import fun1 ImportError: cannot import name fun1 ---------------------------------------------------------------------- Ran 1 test in 0.006s FAILED (errors=1) $ nosetests --verbose --include unit No handlers could be found for logger "nose.plugins" test_from_unit.TestUnit.test_unit ... ok ---------------------------------------------------------------------- Ran 1 test in 0.004s OK $ nosetests --verbose --include functional No handlers could be found for logger "nose.plugins" test_from_functional.TestFunctional.test_functional ... ok ---------------------------------------------------------------------- Ran 1 test in 0.004s OK }}},1154748574,1153500759,[email protected]
3,,color: #777; background: #ddd; border-color: #ccc;,67,Hard to embed tests in existing modules,nose:collector,closed,wontfix,,enhancement,normal,jpellerin,I often like to put a few tests in my Python modules_ and it would be nice to use 'nosetests' on them. However_ nosetests fails to discover any tests because the modules aren't named test_*. Can we have a command-line option that looks for tests in the specified module regardless of its name? I tried making the module executable and using --exe but that didn't work.,1150933585,1149892677,[email protected]
3,,color: #777; background: #ddd; border-color: #ccc;,65,help text in doctest module inaccurate,nose:plugin:doctest,closed,fixed,,minor,normal,jpellerin,... it's just missing the env vars in the help text even though they were being accessed already. (see patch),1149209864,1149178821,Kumar McMillan <[email protected]>
3,,color: #777; background: #ddd; border-color: #ccc;,64,activate non nose loggers through --debug,nose,closed,fixed,,normal,normal,jpellerin,I think that you should be able to activate other loggers for your application through --debug. Imagine I am unit testing a piece of code that uses the logger "application.component". Now_ in the normal run of the application the handler for this is set up by some piece of code that is not being run during the unit test. However_ the unit tests fail_ and I want to quickly activate the logger so I can see what went wrong. I think I should be able to write "nosetests ---debug=application.component" and see the log messages. I have attached a patch that fixes this. ,1149209839,1149119240,[email protected]
2,,color: #777; background: #ddd; border-color: #ccc;,20,nose 0.8.7.1 fails with TurboGears tests,nose,closed,fixed,0.8.7.1,normal,high,jpellerin,Running nosetests from the toplevel directory of a TurboGears trunk checkout fails after this: {{{ Full path to turbogears.fastdata.tests.formmodel is /Users/tazzzzz/projects/turbogears/turbogears.fastdata.tests.formmodel test 'turbogears.fastdata.tests.formmodel' resolves to 'turbogears.fastdata.tests.formmodel' in '/Users/tazzzzz/projects/turbogears' (<class 'nose.core.TestModule'>) running test test module turbogears.fastdata.tests.formmodel in /Users/tazzzzz/projects/turbogears Import turbogears.fastdata.tests.formmodel from /Users/tazzzzz/projects/turbogears }}} It complains of the database not being configured. I am able to import formmodel without any problem from a python prompt_ so it's not just an import that causes a problem. It seems like Nose is actually trying to run something in there.,1143081305,1143047147,kevin