From holger at merlinux.eu Mon Feb 6 00:36:28 2012 From: holger at merlinux.eu (holger krekel) Date: Sun, 5 Feb 2012 23:36:28 +0000 Subject: [py-dev] pytest-2.2.2: bug fixes, collectonly improvements Message-ID: <20120205233628.GK26028@merlinux.eu> pytest-2.2.2 is a minor backward-compatible release of the py.test testing tool. It contains bug fixes and a few refinements particularly to reporting with "--collectonly", see below for betails. For general information see here: http://pytest.org/ To install or upgrade pytest: pip install -U pytest # or easy_install -U pytest Special thanks for helping on this release to Ronny Pfannschmidt and Ralf Schmitt and the contributors of issues. best, holger krekel Changes between 2.2.1 and 2.2.2 ---------------------------------------- - fix issue101: wrong args to unittest.TestCase test function now produce better output - fix issue102: report more useful errors and hints for when a test directory was renamed and some pyc/__pycache__ remain - fix issue106: allow parametrize to be applied multiple times e.g. from module, class and at function level. - fix issue107: actually perform session scope finalization - don't check in parametrize if indirect parameters are funcarg names - add chdir method to monkeypatch funcarg - fix crash resulting from calling monkeypatch undo a second time - fix issue115: make --collectonly robust against early failure (missing files/directories) - "-qq --collectonly" now shows only files and the number of tests in them - "-q --collectonly" now shows test ids - allow adding of attributes to test reports such that it also works with distributed testing (no upgrade of pytest-xdist needed) From basti at rotekroete.de Tue Feb 7 19:38:22 2012 From: basti at rotekroete.de (Sebastian Rahlf) Date: Tue, 7 Feb 2012 19:38:22 +0100 Subject: [py-dev] New plugin pytest-pydev Message-ID: Hello all! I've just released the first version of a new py.test plugin which will allow you to use a remote Python debug server. This will, for instance, come in especially handy if you want to find out why a particular unittest is failing in a web application. Simply fire up your debug server in your IDE (PyDev or PyCharm) e.g. on localhost:8042 and run your unittests with py.test --pydevd=your-ip:8042 If you have set a break point you should soon see the effects. Enjoy! Sebastian P.S. Feedback is always welcome! From basti at rotekroete.de Tue Feb 7 19:40:04 2012 From: basti at rotekroete.de (Sebastian Rahlf) Date: Tue, 7 Feb 2012 19:40:04 +0100 Subject: [py-dev] New plugin pytest-pydev In-Reply-To: References: Message-ID: > Hello all! > > I've just released the first version of a new py.test plugin which > will allow you to use a remote Python debug server. This will, for > instance, come in especially handy if you want to find out why a > particular unittest is failing in a web application. > > Simply fire up your debug server in your IDE (PyDev or PyCharm) e.g. > on localhost:8042 and run your unittests with > > ? ?py.test --pydevd=your-ip:8042 > > If you have set a break point you should soon see the effects. > > Enjoy! > Sebastian > > P.S. Feedback is always welcome! Forgot to mention: code lives on bitbucket.org https://bitbucket.org/basti/pytest-pydev Sorry! Sebastian From anton7811 at gmail.com Thu Feb 16 13:48:15 2012 From: anton7811 at gmail.com (Anton P) Date: Thu, 16 Feb 2012 14:48:15 +0200 Subject: [py-dev] how to access docstrings from pytest_report_teststatus or pytest_runtest_logreport Message-ID: Hi, I'm trying to write my own py.test pluging for extended junitxml reports. This pluging have to parse testcase's docstrings for some additional info for report. I've found the next code in pytest_bugzilla plugin: ??? def pytest_report_teststatus(self,report): ??????? if report.failed: ??????????? if self.analysed(report.item.function.__doc__): ??????????????? return "analysed", "A", "ANALYSED" And I've tried to do the same to access docstrings. But I'm confused, because report object does not contain "item" attribute. At the moment I've added class ExtTestReport(TestReport) and redefined pytest_runtest_makereport() in plugin. The last hook now return report with "item" object. But I think, that redefining native pytest_runtest_makereport() in pluging is not the best idea. Especially because new method is always called regardless of my pluging usage. Please, point me to right solution to access testcase's docstrings from pytest_report_teststatus() or pytest_runtest_logreport(). Thank you in advance! From Ronny.Pfannschmidt at gmx.de Thu Feb 16 14:32:01 2012 From: Ronny.Pfannschmidt at gmx.de (Ronny Pfannschmidt) Date: Thu, 16 Feb 2012 14:32:01 +0100 Subject: [py-dev] how to access docstrings from pytest_report_teststatus or pytest_runtest_logreport In-Reply-To: References: Message-ID: <4F3D0551.5070902@gmx.de> On 02/16/2012 01:48 PM, Anton P wrote: > Hi, > > I'm trying to write my own py.test pluging for extended junitxml > reports. This pluging have to parse testcase's docstrings for some > additional info for report. > > I've found the next code in pytest_bugzilla plugin: > > def pytest_report_teststatus(self,report): > if report.failed: > if self.analysed(report.item.function.__doc__): > return "analysed", "A", "ANALYSED" > > And I've tried to do the same to access docstrings. But I'm confused, > because report object does not contain "item" attribute. > > At the moment I've added class ExtTestReport(TestReport) and redefined > pytest_runtest_makereport() in plugin. The last hook now return report > with "item" object. > > But I think, that redefining native pytest_runtest_makereport() in > pluging is not the best idea. Especially because new method is always > called regardless of my pluging usage. > > Please, point me to right solution to access testcase's docstrings > from pytest_report_teststatus() or pytest_runtest_logreport(). > you can extend the native pytest_runtest_makereport think of something like def pytest_runtest_makereport(__multicall__, ...): rep = __multicall__.execute() rep._docstring = item... return rep -- Regards Ronny > Thank you in advance! > _______________________________________________ > py-dev mailing list > py-dev at codespeak.net > http://codespeak.net/mailman/listinfo/py-dev From anton7811 at gmail.com Fri Feb 17 12:25:16 2012 From: anton7811 at gmail.com (Anton P) Date: Fri, 17 Feb 2012 13:25:16 +0200 Subject: [py-dev] how to access docstrings from pytest_report_teststatus or pytest_runtest_logreport In-Reply-To: <4F3D0551.5070902@gmx.de> References: <4F3D0551.5070902@gmx.de> Message-ID: Thank you! That works for me! -Anton 2012/2/16 Ronny Pfannschmidt : > On 02/16/2012 01:48 PM, Anton P wrote: >> >> Hi, >> >> I'm trying to write my own py.test pluging for extended junitxml >> reports. This pluging have to parse testcase's docstrings for some >> additional info for report. >> >> I've found the next code in pytest_bugzilla plugin: >> >> ? ? def pytest_report_teststatus(self,report): >> ? ? ? ? if report.failed: >> ? ? ? ? ? ? if self.analysed(report.item.function.__doc__): >> ? ? ? ? ? ? ? ? return "analysed", "A", "ANALYSED" >> >> And I've tried to do the same to access docstrings. But I'm confused, >> because report object does not contain "item" attribute. >> >> At the moment I've added class ExtTestReport(TestReport) and redefined >> pytest_runtest_makereport() in plugin. The last hook now return report >> with "item" object. >> >> But I think, that redefining native pytest_runtest_makereport() in >> pluging is not the best idea. Especially because new method is always >> called regardless of my pluging usage. >> >> Please, point me to right solution to access testcase's docstrings >> from pytest_report_teststatus() or pytest_runtest_logreport(). >> > you can extend the native pytest_runtest_makereport > > think of something like > > def pytest_runtest_makereport(__multicall__, ...): > ? rep = __multicall__.execute() > ? rep._docstring = item... > ? return rep > > -- Regards Ronny > >> Thank you in advance! >> _______________________________________________ >> py-dev mailing list >> py-dev at codespeak.net >> http://codespeak.net/mailman/listinfo/py-dev > > From anton7811 at gmail.com Wed Feb 22 12:10:55 2012 From: anton7811 at gmail.com (Anton P) Date: Wed, 22 Feb 2012 13:10:55 +0200 Subject: [py-dev] XML Parsing Error when esc characters are in traceback Message-ID: Hello all, I have the following issue with generated junitxml reports: I'm writing test cases which use scapy functions. So I make asserts on some packet objects. As I understand scapy uses esc characters for its own objects representation, and I can see colorful output on the console. But when test is failed, and its traceback went to xml, I can't open generated xml due to the error "XML Parsing Error: not well-formed" In my case the problem with esc charecter 033 (\x1b). I resolved the issue by adding the following code to append_failure method in LogXML class: longrepr = str(report.longrepr).replace('\x1b', '\\033') fail.append(longrepr) I think that it will be good if you add some cleanup functions to avoid such situations. Thank you, -Anton From flub at devork.be Mon Feb 27 00:19:59 2012 From: flub at devork.be (Floris Bruynooghe) Date: Sun, 26 Feb 2012 23:19:59 +0000 Subject: [py-dev] New plugin: pytest-timeout Message-ID: Hi all, This is to announce the first release of pytest-timeout, a plugin which will interrupt long running (i.e. blocking) tests. This is particularly useful when running the tests on a CI host. When a test is interrupted the stacks of all threads are dumped to stderr, which helps you to locate the reason for the blocking. If the system supports SIGALRM then the test itself is interrupted using pytest.fail() and other tests continue to run, otherwise the stack(s) are dumped to stderr and the process exists immediately. The plugin is available from the cheeseshop: http://pypi.python.org/pypi/pytest-timeout and the code lives at bitbucket: https://bitbucket.org/flub/pytest-timeout/. Feel free to provide any feedback or report issues. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From lpbrac at dolby.com Tue Feb 28 19:08:40 2012 From: lpbrac at dolby.com (Brack, Laurent P.) Date: Tue, 28 Feb 2012 10:08:40 -0800 Subject: [py-dev] New plugin: pytest-timeout References: Message-ID: <05BB196AB3DA6C4BBE11AB6C957581FE42A39DB3@sfo-exch-01.dolby.net> Hi Floris, first of all thanks for this plugin as this is something my team will be more than happy to leverage. I gave it a shot yesterday (just kicking the tires) and while the plugin was installed (see below) and registered it didn't work for me (ubuntu/python 2.6.6) This is py.test version 2.2.3, imported from /home/lpbrac/.buildout/eggs/pytest-2.2.3-py2.6.egg/pytest.pyc setuptools registered plugins: pytest-xdist-1.8 at /home/lpbrac/.buildout/eggs/pytest_xdist-1.8-py2.6.egg/xdist/plugin.pyc pytest-cov-1.5 at /home/lpbrac/.buildout/eggs/pytest_cov-1.5-py2.6.egg/pytest_cov.pyc pytest-testlink-0.0.6 at /home/lpbrac/repos/p4_qa/qa/infrastructure/taf/pytest_plugins/pytest_testlink/src/pytest_testlink/tl_plugin.py pytest-session-cfg-0.0.2 at /home/lpbrac/.buildout/eggs/pytest_session_cfg-0.0.2-py2.6.egg/pytest_session_cfg.py pytest-timeout-0.1 at /home/lpbrac/.buildout/eggs/pytest_timeout-0.1-py2.6.egg/pytest_timeout.pyc Just wrote an infinite loop which never got preempted. I didn't have time to dig any deeper. Does the test need to be executed in a separate process via xdist? Also, currently the time out applies to all tests (and defaults to 5 minutes). I think it would be useful to be able to override the timeout at the test level using markers. If something goes wrong and we have thousands of tests (we use pytest to test embedded systems), this is an awful lot of time to realize that things are DOA. Best Regards and thanks again for starting this. /Laurent -----Original Message----- From: py-dev-bounces at codespeak.net on behalf of Floris Bruynooghe Sent: Sun 2/26/2012 3:19 PM To: py-dev at codespeak.net Subject: [py-dev] New plugin: pytest-timeout Hi all, This is to announce the first release of pytest-timeout, a plugin which will interrupt long running (i.e. blocking) tests. This is particularly useful when running the tests on a CI host. When a test is interrupted the stacks of all threads are dumped to stderr, which helps you to locate the reason for the blocking. If the system supports SIGALRM then the test itself is interrupted using pytest.fail() and other tests continue to run, otherwise the stack(s) are dumped to stderr and the process exists immediately. The plugin is available from the cheeseshop: http://pypi.python.org/pypi/pytest-timeout and the code lives at bitbucket: https://bitbucket.org/flub/pytest-timeout/. Feel free to provide any feedback or report issues. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org _______________________________________________ py-dev mailing list py-dev at codespeak.net http://codespeak.net/mailman/listinfo/py-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Wed Feb 29 11:31:44 2012 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 29 Feb 2012 10:31:44 +0000 Subject: [py-dev] New plugin: pytest-timeout In-Reply-To: <05BB196AB3DA6C4BBE11AB6C957581FE42A39DB3@sfo-exch-01.dolby.net> References: <05BB196AB3DA6C4BBE11AB6C957581FE42A39DB3@sfo-exch-01.dolby.net> Message-ID: Hello Laurent, On 28 February 2012 18:08, Brack, Laurent P. wrote: > Just wrote an infinite loop which never got preempted. I didn't have time to > dig any deeper. Does the test need to be executed in a separate process via > xdist? xdist is not needed, in fact I haven't tried it but assume it will behave fine. By default SIGALM will be used which does have it's limitations, the main issue is that it needs a chance to deliver the signal to python code. So depending on how your infinite loop is written this might be an issue and you may have to consider --nosigalrm which will use a timer thread (this is more expensive obviously). Could you show me the test function you where trying out? > Also, currently the time out applies to all tests (and defaults to 5 > minutes). I think it would be useful to be able to override the timeout > at the test level using markers. If something goes wrong and we have > thousands of tests (we use pytest to test embedded systems), this is an > awful lot of time to realize that things are DOA. Yes, I agree with this and it is noted in the TODO file that individual tests should have some control on the timeout and the mechanism used (timer vs sigalrm). But we only have about 10000 tests running nightly with normally none blocking, this plugin was written on the spur of the moment when we had about a dozen hanging and this minimal functionality seemed to do the job. It does assume hanging tests are an exception rather then the norm, certainly evident from the behaviour of --nosigalrm where os._exit() is called on a hanging test. I'm happy to work with you on adding a marker which will fulfil your needs however. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org