nose: {6} All Tickets By Milestone (Including closed)

#90: Improve logging config options

Wed, 13 Sep 2006 17:31:09 GMT

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.

#85: Is it possible to have more control over TestProgram configuration when running the nose from within python code?

Mon, 28 Aug 2006 19:34:53 GMT

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

#57: .noserc

Sun, 14 May 2006 18:06:41 GMT

Support reading options from a .noserc file or other config file. Format should be the same as command line args (long form), minus the --.

#80: provide TestCase methods as functions.

Sat, 05 Aug 2006 01:49:32 GMT

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

#24: Allow plugins to completely change test output

Fri, 24 Mar 2006 03:12:25 GMT

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.

#27: Missing units

Tue, 28 Mar 2006 04:24:26 GMT

Missing unittests for many core functions: * loader testsInModule * loader FunctionTestCase * loader MethodTestCase * LazySuite.run

#61: Attribute plugin 'OR' test doesn't work

Tue, 23 May 2006 02:28:04 GMT

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.

#59: nose.tools.raises hides module of original test

Wed, 17 May 2006 20:32:25 GMT

When using nose.tools.raises, the test reports look like: {{{ nose.tools. }}} Instead of: {{{ . }}} raises needs to set the name or module of the wrapper it returns properly.

#58: ArrtibuteError running nosetests

Wed, 17 May 2006 15:17:06 GMT

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.

#54: ignore all executable files?

Wed, 03 May 2006 02:20:44 GMT

* Is this desirable? (YES) * Is it possible to do, dependably, cross-platform? (YES)

#51: nose.collector causes loop when running `setup.py test`

Mon, 01 May 2006 15:50:59 GMT

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.

#53: plugin import errors kill test run

Mon, 01 May 2006 18:21:39 GMT

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.

#52: profile plugin shadows builtin profile module

Mon, 01 May 2006 18:18:29 GMT

It needs a name change, causes nosetests to fail to load on some platforms.

#56: wantFunction and wantMethod bugs in attr [patch]

Fri, 05 May 2006 15:32:13 GMT

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

#55: bug in doctest plugin loadTestsFromPath [patch]

Wed, 03 May 2006 15:18:43 GMT

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 ...

#50: Update mkrelease

Mon, 24 Apr 2006 00:30:10 GMT

Update mkrelease to make svn/svk branch and tag instead of bzr.

#4: doc -> wiki

Thu, 09 Mar 2006 02:51:18 GMT

Add a script similiar to mkindex.py that posts doc updates to the right places in this wiki.

#49: Update docs for 0.9

Sun, 23 Apr 2006 23:57:41 GMT

* 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

#37: setuptools integration phase 2: disable plugins

Tue, 11 Apr 2006 02:53:09 GMT

When run under setuptools, should disable plugins that implement methods that won't get a chance to run (report, finalize, prepareTest, setOutputStream).

#48: logging behavior: ignore root logger settings

Sat, 22 Apr 2006 01:02:16 GMT

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.

#46: super?

Tue, 18 Apr 2006 15:00:45 GMT

Check usage of super() vs direct __init__ calls. Ref: http://fuhm.net/super-harmful/

#44: disable attrib plugin eval option for versions < 2.4

Tue, 18 Apr 2006 03:09:26 GMT

eval() can't take an instance in 2.3, so the attrib eval() option must be disabled in 2.3.

#45: Fix tests for 2.3

Tue, 18 Apr 2006 03:15:34 GMT

Many tests are failing under 2.3 due to incompatibile iteration, etc.

#43: nosetests bad_file.py -> greedy loads

Sun, 16 Apr 2006 04:15:13 GMT

When given a bad file name, nosetests loads tests from all modules instead of issuing a warning.

#42: nosetests relative/path.py -> no tests loaded

Sun, 16 Apr 2006 04:13:25 GMT

Test name resolution for relative filenames is wrong. The files are not loaded.

#41: profiler plugin is broken

Sun, 16 Apr 2006 04:09:49 GMT

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 "", 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 }}}

#40: stop on first error

Thu, 13 Apr 2006 14:08:57 GMT

Suggestion from Kevin Dangoor: Add an option to stop running tests on the first failure.

#36: loader.loadTestsFromNames behavior

Sun, 09 Apr 2006 00:49:00 GMT

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.

#34: nose.main signature does not match unittest.main

Fri, 07 Apr 2006 02:38:41 GMT

nose.main should be usable interchangably with unittest.main.

#33: coverage plugin: option to erase before run

Mon, 03 Apr 2006 03:34:40 GMT

The coverage plugin should have an option to allow the user to erase accumulated stats before a test run.

#32: revise setuptools support, phase 1

Sat, 01 Apr 2006 04:37:47 GMT

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)

#31: nose.tools

Fri, 31 Mar 2006 14:56:39 GMT

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.

#14: test generators for methods do not work

Sat, 18 Mar 2006 17:28:15 GMT

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.

#25: profiler: output controls

Fri, 24 Mar 2006 03:22:51 GMT

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

#10: document plugin interfaces

Sat, 11 Mar 2006 15:26:46 GMT

Document the collector, selector and watcher methods that plugins can implement and where they are called in the process.

#22: loading tests from classes: beware subclassing

Fri, 24 Mar 2006 01:02:35 GMT

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

#8: warn on missed test names

Thu, 09 Mar 2006 15:04:10 GMT

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.

#30: pass captured output to plugins

Tue, 28 Mar 2006 05:05:47 GMT

In addError and addFailure, pass captured output (if any) to plugin calls.

#29: _import failure

Tue, 28 Mar 2006 04:31:19 GMT

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 }}}

#19: watcher plugin API: access to test results

Wed, 22 Mar 2006 15:34:34 GMT

make it easier for watcher plugins to access test results... possibly call addError, etc, in plugins from TextTestResult.

#16: unit tests for plugin option handling

Sat, 18 Mar 2006 23:09:08 GMT

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

#26: func_names -> funcNames

Sat, 25 Mar 2006 04:43:26 GMT

Much as I hate camelCase, unittest uses it and some overridden methods must use it, so for consistency, everythingShouldLookLikeThis.

#23: refactor: revise for better unittest compatibility

Fri, 24 Mar 2006 01:11:37 GMT

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.

#18: setUpModule doesn't work

Wed, 22 Mar 2006 15:12:33 GMT

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')

#2: implement profiler plugin

Thu, 09 Mar 2006 02:46:26 GMT

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).

#17: improve library discovery

Mon, 20 Mar 2006 21:18:57 GMT

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).

#5: 'EOF in multiline input'

Thu, 09 Mar 2006 03:04:38 GMT

Assert introspection fails for many expressions with an error like 'EOF in multiline input'

#15: attrib plugin env defaults should not be strings

Sat, 18 Mar 2006 23:07:30 GMT

The attrib plugin is currently broken because the option defaults are strings, but the option type is append.

#9: use logging for messaging

Sat, 11 Mar 2006 15:24:14 GMT

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

#7: add option to activate pdb on error/fail

Thu, 09 Mar 2006 03:30:53 GMT

Add command line option/env var to activate the pdb on error/fail feature.

#6: patch AssertionError only

Thu, 09 Mar 2006 03:05:41 GMT

Install the patch that introspects assets as AssertionError only, instead of patching builtin.Exception.

#12: patch: attribute-based test case selector

Sun, 12 Mar 2006 20:01:49 GMT

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.

#11: patch: Windows path handling issues

Sun, 12 Mar 2006 11:22:20 GMT

Nose 0.9 r5 fails to run any test cases on Windows. Here's a patch with fixes to some path handling issues. - Mika

#3: use clean config in units

Thu, 09 Mar 2006 02:49:15 GMT

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.

#113: python setup.py nosetests --stop was raise TypeError

Tue, 12 Dec 2006 01:15:15 GMT

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

#110: isolation plugin

Sat, 02 Dec 2006 17:31:53 GMT

Include a plugin in core that resets the state of sys.modules between after each test module is run.

#109: doctest vs coverage

Fri, 01 Dec 2006 20:02:22 GMT

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.

#108: Generate and post plugin docs

Wed, 22 Nov 2006 15:30:56 GMT

Generate HTML docs for built-in plugins and post them to the site and wiki.

#106: Revise long description in setup.py

Tue, 21 Nov 2006 15:48:27 GMT

Revise the long description in setup.py to be more accurate and descriptive.

#100: nosetests man page

Sat, 28 Oct 2006 22:06:05 GMT

Install a man page for nosetests on install. A man page contributed by Gustavo Noronha Silva is attached to this ticket.

#112: test can't be run from package directory -- misleading INFO message

Mon, 11 Dec 2006 16:46:06 GMT

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?

#102: Nose frontpage installation instructions in error

Sun, 05 Nov 2006 23:26:24 GMT

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.

#95: evaluating asserts stops working when there is a two-line docstring

Wed, 04 Oct 2006 21:21:27 GMT

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

#101: Doesn't select decorated methods/functions

Wed, 01 Nov 2006 21:02:07 GMT

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.

#111: nosetests -vvvv produces little output

Tue, 05 Dec 2006 18:35:32 GMT

You get more output with -v, -vv, and -vvv -- but with -vvvv the output goes away

#105: nose 0.9.1 does not run functional tests in order of appearance in the module

Thu, 16 Nov 2006 20:59:35 GMT

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.

#79: ability to change the regex pattern

Tue, 01 Aug 2006 23:48:00 GMT

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?

#107: Expose the guts of @raises as assert_raises

Wed, 22 Nov 2006 15:18:08 GMT

@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.

#39: setuptools integration: pick up options from setup.cfg

Thu, 13 Apr 2006 14:07:55 GMT

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.

#38: setuptools integration phase 3: custom command

Tue, 11 Apr 2006 02:54:05 GMT

Create a setuptools command that exposes the full functionality of nose and all plugins.

#99: integrated twisted with nose

Wed, 25 Oct 2006 17:46:42 GMT

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.

#92: @with_setup doesn't mix well with @raises

Mon, 25 Sep 2006 15:52:56 GMT

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(): ...

#98: @with_setup not calling teardown() if test raises exception

Thu, 12 Oct 2006 19:28:14 GMT

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

#94: --doctest-extension and NOSE_DOCTEST_EXTENSION conflict

Thu, 28 Sep 2006 02:33:39 GMT

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' }}}

#93: try:except: around inspect.getargspec

Thu, 28 Sep 2006 00:09:08 GMT

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.

#96: Names of modules in test packages

Wed, 04 Oct 2006 22:20:30 GMT

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.

#91: python 2.5: assert introspection: different line counts

Tue, 19 Sep 2006 17:24:17 GMT

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.

#76: No handlers for logger spam

Fri, 21 Jul 2006 16:00:36 GMT

No handlers could be found for logger "nose.plugins" is spammed to the console sometimes(?) on startup.

#86: python version detection broken for 3.0 and above

Thu, 31 Aug 2006 14:08:54 GMT

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) }}}

#81: /lib -style package organization broken

Tue, 08 Aug 2006 14:22:55 GMT

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.

#83: -x/--stop stops on skipped tests

Thu, 24 Aug 2006 21:51:17 GMT

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.

#75: Multiple --include arguments should 'OR' not override

Fri, 21 Jul 2006 15:58:16 GMT

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.

#78: option for coverage to include all .py files

Sat, 29 Jul 2006 15:08:58 GMT

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.

#72: package.mod:Class doesn't select all tests in class

Thu, 06 Jul 2006 16:36:31 GMT

It looks like package.mod:Class is broken; it doesn't select all of the tests in the class -- it selects nothing.

#74: Possible bug in subpackage_of

Wed, 19 Jul 2006 19:50:46 GMT

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.

#60: Add function that works like unittest.main(): collects tests in main only

Wed, 17 May 2006 21:16:24 GMT

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() }}}

#62: Allow multiple -w arguments

Thu, 25 May 2006 00:15:07 GMT

nosetests should allow multiple -w arguments to include multiple test roots in one run.

#73: nose.collector not finding all tests in `setup.py test`

Thu, 06 Jul 2006 22:10:49 GMT

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?

#71: nosetests -s results in IOError: [Errno 29] Illegal seek

Wed, 28 Jun 2006 12:55:39 GMT

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.

#70: Missing file warning spam

Fri, 23 Jun 2006 13:58:58 GMT

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.

#69: All python files are executable on windows

Mon, 12 Jun 2006 10:11:30 GMT

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.

#21: add unittests for lunatic objects

Thu, 23 Mar 2006 02:43:52 GMT

Add unittests for weirdo calls that might come up, such as calling want_function() with something that doesn't have a {{{__name__}}}.

#1: coverage output for single tests

Thu, 09 Mar 2006 02:43:25 GMT

Ran: {{{ python nose/core.py -vvvvv -w st/unit_tests --with-coverage --cover-package=nose test_selector }}} Expected: coverage output Actual: no coverage output

#68: The meaning of '--exe' is backwards

Mon, 12 Jun 2006 09:40:57 GMT

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.

#66: specifying test names causes repeat imports

Thu, 08 Jun 2006 14:36:33 GMT

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 }}}

#63: TypeError: iteration over non-sequence

Tue, 30 May 2006 20:31:34 GMT

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.

#35: profiler: output to stream or file

Fri, 07 Apr 2006 03:23:58 GMT

The profiler plugin should be able to output to the results stream or a selected file.

#28: Missing units

Tue, 28 Mar 2006 04:24:27 GMT

Missing unittests for many core functions: * loader testsInModule * loader FunctionTestCase * loader MethodTestCase * LazySuite.run

#104: rewrite test loading/importing/suites to be easier to follow

Mon, 13 Nov 2006 22:45:44 GMT

The code for test loading, suites and imports is convoluted and difficult to follow. It should be simplified and clarified.

#103: Run fictures (setup/teardown) only for modules or packages that contain tests

Sun, 12 Nov 2006 15:33:08 GMT

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.

#89: would like common interface for all test wrapper objects

Mon, 11 Sep 2006 19:58:37 GMT

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.

#84: Generator tests with mutable arguments = bad

Fri, 25 Aug 2006 17:04:44 GMT

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. }}}

#13: update selftest.py

Thu, 16 Mar 2006 04:29:27 GMT

Update selftest to account for the new tests in units and unit support.

#114: nosetests 0.9.1 leaks 0-byte temporary files under Windows

Mon, 18 Dec 2006 02:01:55 GMT

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.

#47: optimize startup time for lib/ test/ and package/ test/ cases

Tue, 18 Apr 2006 15:02:55 GMT

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.

#97: @with_setup not calling teardown() if test raises exception

Thu, 12 Oct 2006 19:28:00 GMT

#87: nose-django fails for apps with no models.py

Tue, 05 Sep 2006 07:58:58 GMT

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.

#88: call to debug log raises IndexError

Tue, 05 Sep 2006 14:55:03 GMT

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.

#82: NameError in class def only when running nosetests

Thu, 17 Aug 2006 20:28:12 GMT

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

#77: Importer bug for modules starting with underscore

Fri, 21 Jul 2006 16:52:39 GMT

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 }}}

#67: Hard to embed tests in existing modules

Fri, 09 Jun 2006 22:37:57 GMT

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.

#65: help text in doctest module inaccurate

Thu, 01 Jun 2006 16:20:21 GMT

... it's just missing the env vars in the help text even though they were being accessed already. (see patch)

#64: activate non nose loggers through --debug

Wed, 31 May 2006 23:47:20 GMT

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.

#20: nose 0.8.7.1 fails with TurboGears tests

Wed, 22 Mar 2006 17:05:47 GMT

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' () 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.