Mailman 3 August 2008 - pytest-dev

[py-dev] py.test and editors (Re: [issue57] Emacs and py.test tracebacks)
by holger krekel Aug. 13, 2008

Aug. 13, 2008

Hi folks, yesterday, Harald asked me on #pylib regarding integration of py.test with Scite and just now i replied to a similar issue that Osmo posted on the issue tracker. See below. I'd like to ask here as well: What would you like for py.test's output in order for it to be most helpful with your mode of testing and particularly integration with editors? You may also subscribe to https://codespeak.net/issue/py-dev/issue57 if you want to follow the implementation of this feature. cheers, holger P.S.: i am thinking of putting out a 0.9.2 with a few fixes. If you have anything *now* is a good time to file. -- collaborative expert contracting: http://merlinux.eu PyPy Python/Compiler tool chain: http://codespeak.net/pypy pylib py.test/greenlets/svn APIs: http://pylib.org ----- Forwarded message from holger krekel <hpk(a)trillke.net> ----- From: holger krekel <hpk(a)trillke.net> To: Osmo Salomaa <py-dev-issue(a)codespeak.net> Cc: hpk(a)trillke.net, otsaloma(a)cc.hut.fi Subject: Re: [issue57] Emacs and py.test tracebacks User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Spambayes-Classification: ham; 0.00 Hi Osmo, thanks for your report! If you have the following test_file.py: def somefunc(): assert 0 def test_func(): somefunc() you would probably like to get /full/path/to/test_file1.py:3 in a line somewhere in the long traceback for this failing test function, right? What do you think about always adding a "summary" at the end of a test run that looks like this? /full/path/to/test_file1.py:3 AssertionError: 0 /full/path/to/test_file3.py:47 ValueError: 0 ... ... Or, to ask more generally, what would be most helpful output for your mode of testing with emacs? holger On Wed, Jul 23, 2008 at 04:35 +0000, Osmo Salomaa wrote: > New submission from Osmo Salomaa <otsaloma(a)cc.hut.fi>: > > Currently the filename and line numbers in py.test's long tracebacks are of form > "[FILENAME:LINENO]". Emacs's compilation buffer does not understand that format. > Changing it to form "FILENAME:LINENO:" (no brackets and a trailing colon) allows > Emacs to parse that and render it as a clickable link. Emacs is able to parse > the filenames and line numbers in the short tracebacks, but the links don't work > because it would require the full filepath. > > I suspect other editors may suffer similarly, because there is no easy way to > know that the opening bracket is not a part of the filename. > > Based on a quick look only a one line change to py/test/representation.py, > method 'repr_failure_tblong' would be needed to fix the long tracebacks. > > ---------- > effort: easy > messages: 147 > nosy: hpk, otsaloma > priority: wish > release: ??? > status: unread > title: Emacs and py.test tracebacks > > _______________________________________________________ > py lib development tracker <py-dev-issue(a)codespeak.net> > <https://codespeak.net/issue/py-dev/issue57> > _______________________________________________________ > -- collaborative expert contracting: http://merlinux.eu PyPy Python/Compiler tool chain: http://codespeak.net/pypy pylib py.test/greenlets/svn APIs: http://pylib.org ----- End forwarded message -----

3 26

[py-dev] SyntaxWarning: assertion is always true
by Ralf Schmitt Aug. 13, 2008

Aug. 13, 2008

Hi, minor issue, but you probably want to fix it: /home/ralf/py26/lib/python2.6/site-packages/py-0.9.2_pre_alpha-py2.6-linux-x86_64.egg/py/apigen/linker.py:33: SyntaxWarning: assertion is always true, perhaps remove parentheses? assert (linkid not in self._linkid2target, - Ralf

2 1

[py-dev] Exceptions in setup/teardown hooks
by Matthew Edwards Aug. 11, 2008

Aug. 11, 2008

Hi, I've got some tests for a module which manages log files. The setup_class and teardown_class functions create and delete a directory for them, and the teardown_method function deletes the individual files based on a list. When a test fails, it can leave files which aren't on the list, so don't get deleted in teardown_method, which makes teardown_class choke on os.rmdir (because the directory is not empty). While I do need to know if there are files left over, the problem is that when an exception occurs in a hook, it shows a traceback for that only, and not the actual test failure, so I can't tell what failed. Am I just doing this wrong, or is this a bit of a bug? I would prefer an exception in [setup|teardown]_method to fail that method, and an exception in [setup|teardown]_class to fail all the tests in that class, and if an exception is raised in a test and the following hook, tracebacks for both should be displayed. As an aside, stdout capture doesn't work particularly well from the hooks either. Matthew

3 2

Re: [py-dev] Exceptions in setup/teardown hooks
by Matthew Edwards Aug. 11, 2008

Aug. 11, 2008

Thanks, I'll try that. It's just that it's likely I'll end up moving stuff from [setup|teardown]_* into other functions which I call manually (or possibly magically) before and after each test, which seems a bit counterproductive. Matthew On Mon, Aug 11, 2008 at 6:33 PM, Neil Shepperd <nshepperd(a)gmail.com> wrote: > On Mon, 2008-08-11 at 08:17 +1200, Matthew Edwards wrote: > > Hi, > > > > I've got some tests for a module which manages log files. The > > setup_class and teardown_class functions create and delete a directory > > for them, and the teardown_method function deletes the individual > > files based on a list. When a test fails, it can leave files which > > aren't on the list, so don't get deleted in teardown_method, which > > makes teardown_class choke on os.rmdir (because the directory is not > > empty). While I do need to know if there are files left over, the > > problem is that when an exception occurs in a hook, it shows a > > traceback for that only, and not the actual test failure, so I can't > > tell what failed. > If having no files left over is necessary for the test to pass, > that should be part of the test. You should probably use rmtree > in the hook, as hooks are not tests, and must always work - independent > of whether the test itself passes. > > > > Am I just doing this wrong, or is this a bit of a bug? I would prefer > > an exception in [setup|teardown]_method to fail that method, and an > > exception in [setup|teardown]_class to fail all the tests in that > > class > May be a bad idea. IMHO setup/teardown should do just what they're > called - setup and teardown an environment for tests to run in. If > an exception occurs in [setup|teardown]_* it should be because your > setup/teardown code is broken. Mixing up setup/teardown with tests > themselves seems like a mistake to me. > > Neil Shepperd >

1 0