Mailman 3 May 2010 - pytest-dev

[py-dev] New issue 103 in py-trunk: Introduce "with py.test.raises(...)"
by issues-noreply＠bitbucket.org May 29, 2010

May 29, 2010

--- you can reply above this line --- New issue 103: Introduce "with py.test.raises(...)" http://bitbucket.org/hpk42/py-trunk/issue/103/introduce-with-pytestraises holger krekel / hpk42 on Sat, 29 May 2010 15:47:47 +0200: Description: For those who want to keep their code compatible to >=Python2.6 it'd be nice to extend py.test.raises with a third form: {{{ with py.test.raises(ValueError) as excinfo: #codeblock }}} which would be equivalent to using the previous string-notation: {{{ excinfo = py.test.raises(ValueError, "#codeblock") }}} I believe this could be implemented in a manner that preserves py.test's single-source nature for Python2.4-Python3.1. And i wonder if there are other potential extensions/uses for newer syntax. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] New issue 101 in py-trunk: Add pytest-cov to plugins page?
by issues-noreply＠bitbucket.org May 27, 2010

May 27, 2010

--- you can reply above this line --- New issue 101: Add pytest-cov to plugins page? http://bitbucket.org/hpk42/py-trunk/issue/101/add-pytest-cov-to-plugins-page memedough on Tue, 25 May 2010 12:16:58 +0200: Description: Hi, Would you be agreeable to adding pytest-cov to the plugins page? I've been using it for a while now and it's performing well and stable for my usage pattern. It provides another option and may be useful for others. :) Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

3 3

[py-dev] pytest-xdist-1.3 fixes and a sidenote/tip
by holger krekel May 25, 2010

May 25, 2010

Hi again, i also uploaded a new pytest-xdist-1.3 plugin to the package index which requires the new py-1.3.1. Main thing: If you experienced the strange phenomenon of -f|--looponfail to show tracebacks with _old_ source code, this release should fix that. It also adjusts to the new --maxfail=NUM option of py.test so that in a distributed test run this option works properly: aborting the test run if more then the maximum number of failures are encountered, bringing all nodes down. Btw, did you know you can set this as well as other options through your shell environment or a conftest.py file? For example, export PYTEST_OPTION_MAXFAIL=3 # in bash or option_maxfail = 3 # in conftest.py to always abort test runs after three failures. To find out about available ENV or conftest.py names type py.test --help-config best, holger

1 0

[py-dev] py.test-1.3.1: new py.test.xfail, --maxfail, better reporting, fixes
by holger krekel May 25, 2010

May 25, 2010

The pylib/py.test 1.3.1 release brings: - the new imperative ``py.test.xfail()`` helper in order to have a test or setup function result in an "expected failure" - a new option ``--maxfail=NUM`` to stop the test run after some failures - markers/decorators are now applicable to test classes (>=Python2.6) - improved reporting, shorter tracebacks in several cases - some simplified internals, more compatibility with Jython and PyPy - bug fixes and various refinements See the below CHANGELOG entry below for more details and http://pylib.org/install.html for installation instructions. If you used older versions of py.test you should be able to upgrade to 1.3.1 without changes to your test source code. py.test is an automated testing tool working with Python2, Python3, Jython and PyPy versions on all major operating systems. It offers a no-boilerplate testing approach and has inspired other testing tools and enhancements in the standard Python library for more than five years. It has a simple and extensive plugin architecture, configurable reporting and provides unique ways to make it fit to your testing process and needs. See http://pytest.org for more info. cheers and have fun, holger krekel Changes between 1.3.0 and 1.3.1 ================================================== New features ++++++++++++++++++ - issue91: introduce new py.test.xfail(reason) helper to imperatively mark a test as expected to fail. Can be used from within setup and test functions. This is useful especially for parametrized tests when certain configurations are expected-to-fail. In this case the declarative approach with the @py.test.mark.xfail cannot be used as it would mark all configurations as xfail. - issue102: introduce new --maxfail=NUM option to stop test runs after NUM failures. This is a generalization of the '-x' or '--exitfirst' option which is now equivalent to '--maxfail=1'. Both '-x' and '--maxfail' will now also print a line near the end indicating the Interruption. - issue89: allow py.test.mark decorators to be used on classes (class decorators were introduced with python2.6) and also allow to have multiple markers applied at class/module level by specifying a list. - improve and refine letter reporting in the progress bar: . pass f failed test s skipped tests (reminder: use for dependency/platform mismatch only) x xfailed test (test that was expected to fail) X xpassed test (test that was expected to fail but passed) You can use any combination of 'fsxX' with the '-r' extended reporting option. The xfail/xpass results will show up as skipped tests in the junitxml output - which also fixes issue99. - make py.test.cmdline.main() return the exitstatus instead of raising SystemExit and also allow it to be called multiple times. This of course requires that your application and tests are properly teared down and don't have global state. Fixes / Maintenance ++++++++++++++++++++++ - improved traceback presentation: - improved and unified reporting for "--tb=short" option - Errors during test module imports are much shorter, (using --tb=short style) - raises shows shorter more relevant tracebacks - --fulltrace now more systematically makes traces longer / inhibits cutting - improve support for raises and other dynamically compiled code by manipulating python's linecache.cache instead of the previous rather hacky way of creating custom code objects. This makes it seemlessly work on Jython and PyPy where it previously didn't. - fix issue96: make capturing more resilient against Control-C interruptions (involved somewhat substantial refactoring to the underlying capturing functionality to avoid race conditions). - fix chaining of conditional skipif/xfail decorators - so it works now as expected to use multiple @py.test.mark.skipif(condition) decorators, including specific reporting which of the conditions lead to skipping. - fix issue95: late-import zlib so that it's not required for general py.test startup. - fix issue94: make reporting more robust against bogus source code (and internally be more careful when presenting unexpected byte sequences)

1 0

[py-dev] New issue 102 in py-trunk: Allow -x to take an argument
by issues-noreply＠bitbucket.org May 25, 2010

May 25, 2010

--- you can reply above this line --- New issue 102: Allow -x to take an argument http://bitbucket.org/hpk42/py-trunk/issue/102/allow-x-to-take-an-argument alex_gaynor on Tue, 25 May 2010 12:29:29 +0200: Description: Right now -x doesn't take an arguments, and it just stops the tests after a single failure. Sometimes I want to see a few failures, but not all 100 :) If -x had an argument it would basically run the tests up until that number of errors/failures. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] New issue 100 in py-trunk: Please tag pytest-xdist 1.2
by issues-noreply＠bitbucket.org May 25, 2010

May 25, 2010

--- you can reply above this line --- New issue 100: Please tag pytest-xdist 1.2 http://bitbucket.org/hpk42/py-trunk/issue/100/please-tag-pytest-xdist-12 memedough on Tue, 25 May 2010 11:52:39 +0200: Description: Hi, The pytest-xdist mercurial repo has no tag for release 1.2 which is on pypi. Please add tag. :) Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] New issue 99 in py-trunk: unexpected pass crashes with junitxml plugin
by issues-noreply＠bitbucket.org May 20, 2010

May 20, 2010

--- you can reply above this line --- New issue 99: unexpected pass crashes with junitxml plugin http://bitbucket.org/hpk42/py-trunk/issue/99/unexpected-pass-crashes-with-j… Anonymous on Fri, 21 May 2010 04:20:55 +0200: Description: Unexpected pass should cause the tests to report failure, however with the junitxml plugin it crashes with the following: INTERNALERROR> def append_failure(self, report): INTERNALERROR> self._opentestcase(report) INTERNALERROR> #msg = str(report.longrepr.reprtraceback.extraline) INTERNALERROR> self.appendlog('<failure message="test failure">%s</failure>', INTERNALERROR> > report.longrepr) INTERNALERROR> E AttributeError: 'ItemTestReport' object has no attribute 'longrepr' -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

Re: [py-dev] Running the least run test
by holger krekel May 20, 2010

May 20, 2010

Hi Simon, On Mon, May 17, 2010 at 16:27 +0100, Simon Callan wrote: > Having got good answers to my previous questions, I'm back for more help, > with a few related questions. > > 1) Is it possible to programmatically stop py.test halfway through running a > set of tests? I.e., for an external program to say "complete the current > test and then stop". That's not easily possible although distributed testing internally this feature. Can you create an enhancement issue and maybe describe your use case / intention of using it a bit more? This helps me a lot to avoid coding features nobody needs. > 2) If I have a number of tests (let's say a1 to a5), and I aborted the test > during the running of test a3, is it possible for the next invocation of > py.test to remember where it got to, and start running again at test a4? Rerunning the last failure(s) and continuing on would probably be nice. It's not possible currently, requires adding some persistence between py.test invocations. Could you also create an issue? If you or somebody else has anything to add or to suggest, shoot :) holger

2 1

[py-dev] Problems with test discovery (ImportError)
by Hans Meine May 20, 2010

May 20, 2010

Hi, I had successfully toyed with py.test in the past, and just wanted to use it again, instead of nosetests. However, py.test fails with E ImportError: No module named something.test_foo This seems to be caused by a package subdirectory called 'io'. Here's how to reproduce this (not necessarily minimal yet): mkdir -p test_ImportError/io/something touch test_ImportError/io/something/test_foo.py touch test_ImportError/io/something/__init__.py touch test_ImportError/io/__init__.py py.test test_ImportError/io/something Obviously, this is a bug that should be fixed, but I would already happy if you could tell me a workaround (i.e. different invocation of py.test, without changing the directory name of course). Have a nice day, Hans PS: Please CC me as I did not subscribe for this single report. Thanks.

2 3

[py-dev] Running the least run test
by Simon Callan May 17, 2010

May 17, 2010

Hi, Having got good answers to my previous questions, I'm back for more help, with a few related questions. 1) Is it possible to programmatically stop py.test halfway through running a set of tests? I.e., for an external program to say "complete the current test and then stop". 2) If I have a number of tests (let's say a1 to a5), and I aborted the test during the running of test a3, is it possible for the next invocation of py.test to remember where it got to, and start running again at test a4? Simon Infoshare Ltd Millennium House 21 Eden Street Kingston upon Thames Surrey KT1 1BL United Kingdom Phone: + 44 (0) 20 8541 0111 Support: + 44 (0) 20 8481 4760 Web: www.infoshare-is.com E-mail: info(a)infoshare-is.com Infoshare Ltd is registered in England and Wales. Registered Office as above. Registered Number 2877612 VAT Number GB 678 1443 10 The content of this e-mail (and any attachment to it) is confidential. Any views or opinions do not represent the views or opinions of Infoshare Ltd. If you have received this e-mail in error please notify the sender and delete it. You may not use, copy or disclose the information in any way. Infoshare Ltd monitors incoming and outgoing e-mails. Please consider the environment. Do you really need to print this email?

1 0