Mailman 3 May 2012 - pytest-dev

[py-dev] pytest-timeout 0.2
by Floris Bruynooghe June 20, 2012

June 20, 2012

Hi all, I've made a second release of the pytest-timeout plugin for py.test which can time out long running tests. This release includes a number of suggestions made on this list, major changes include: * Fixed the activation problem * Set timeout using configuration file * Add a timeout marker to modify timeout of one item * The marker can also choose the method (signal/thread) * Renamed --nosigalrm to --timeout_method to future proof adding of eventlet and gevent timeout methods * Works on python 3, tested on 2.6, 2.7 and 3.2 Not yet done: * Automatic enabling of the plugin, you still need to enable it on the command line or configuration file before you can use the marker. This was probably a bad idea but I felt bad about stealing a marker by default. * eventlet and gevent timeouts As before the release is on pypi: http://pypi.python.org/pypi/pytest-timeout and the development repository and issue tracker on bitbucket: https://bitbucket.org/flub/pytest-timeout/ I'd be pleased to receive any further feedback you may have. Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

3 8

[py-dev] pytest documents with Japanese translation
by Tetsuya Morimoto June 7, 2012

June 7, 2012

Hi, I finished translating pytest documents English to Japanese. My repository is below and I made the named branch "2.2.3-ja" for translating docs. https://bitbucket.org/t2y/pytest-ja I would like to publish this Japanese translation on pytest.org with some ways. But, I don't know it's possible or not, and how to deploy the current docs. I think putting original and translated docs separately is easy deployment to avoid some conflicts. Of course, other suggestions are welcome. Additionally, I can maintain Japanese docs in the future. So, I can work by myself if you give me needed permission. thanks, Tetsuya

3 14

[py-dev] Performance tests with py.test
by Bogdan Opanchuk June 4, 2012

June 4, 2012

Hello, I am trying to wrap performance tests for my module into py.test. Each testcase is, basically, a data preparation stage (can take some time) and the test itself. Is there some way (hooks, plugins) to make py.test print the value returned from the testcase (and make testcases time whatever they want)? What I want is just a table like the one after "py.test -v", but with return values instead of "PASSED". I googled it and haven't found any solutions. At the moment I am doing it as following: 1. Overload "pytest_pyfunc_call()" and save returned result into "pyfuncitem" parameter. 2. Overload "pytest_runtest_makereport()", look for "perf" mark and somehow output "item.result". 3. I haven't decided about the way to output it yet, because I am currently trying to find the place where "PASSED" is printed. But this seems quite clunky and overcomplicated. Is there any better way to do this? If not for the data preparation, the currently existing time measuring system would probably be enough for me (although I'd still miss the ability to print GFLOPS value instead of seconds), but the data preparation is testcase-specific and I do not want to move it to "pytest_generate_tests()" hook. Thank you in advance.

2 4

[py-dev] pytest-2.2.4 - bugfixes and better junitxml/unittest/python3 compat
by holger krekel May 22, 2012

May 22, 2012

pytest-2.2.4: bug fixes, better junitxml/unittest/python3 compat =========================================================================== pytest-2.2.4 is a minor backward-compatible release of the versatile py.test testing tool. It contains bug fixes and a few refinements to junitxml reporting, better unittest- and python3 compatibility. 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 Benjamin Peterson and the contributors of issues. best, holger krekel Changes between 2.2.3 and 2.2.4 ----------------------------------- - fix error message for rewritten assertions involving the % operator - fix issue 126: correctly match all invalid xml characters for junitxml binary escape - fix issue with unittest: now @unittest.expectedFailure markers should be processed correctly (you can also use @pytest.mark markers) - document integration with the extended distribute/setuptools test commands - fix issue 140: propperly get the real functions of bound classmethods for setup/teardown_class - fix issue #141: switch from the deceased paste.pocoo.org to bpaste.net - fix issue #143: call unconfigure/sessionfinish always when configure/sessionstart where called - fix issue #144: better mangle test ids to junitxml classnames - upgrade distribute_setup.py to 0.6.27

1 0

[py-dev] Pytest 2.2.4 release timeframe?
by Erik Tollerud May 19, 2012

May 19, 2012

Hello, I was just curious if there's any rough timeline/plan for a 2.2.4 release of pytest? I'm particularly interested in the fix for the pastebin option being in a released version, as we use this in our test reports in a project I work on. We can, of course, use the latest developer version, but it seems better practice to include a released version we bundle in our package... -- Erik Tollerud

2 2

[py-dev] Change behavior in pytest_runtest_setup hooks based on available funcargs
by Andreas Pelme May 2, 2012

May 2, 2012

Hi, I am trying to implement a live_server funcarg, which will manage a Django LiveServerThread, passing in the live server URL to the test function. pytest_runtest_setup is used to start a database transaction, and then pytest_runtest_teardown will rollback the transaction after the test run - this is the standard way Django's TestCase works. I also have a pytest mark: transaction_test_case, when used, instead of running the test in a transaction and rolling back at the end, the database is flushed (this is equivalent to Django's TransactionTestCase). When running tests with the live_server funcarg, the live server is running in another thread, and the data needs to be committed to the database, in order for the live server to see the data. So, transaction_test_case behavior should always be used when the live_server funcarg is used. The relevant code is available here: https://gist.github.com/9a090afd645026b34bfb I would like to change behavior in my pytest_runtest_setup hook, when a certain funcarg is used. The problem is that funcargs are not available in item.keywords in pytest_runtest_setup (since the pytest_funcarg__*() functions have not yet been called). When pytest_runtest_teardown is called however, item.keywords are available, and the database can be teared down in the right way. I am using request.applymarker(transaction_test_case) in pytest_funcarg__live_server(), but as stated above, it won't be visible in pytest_runtest_setup. It would be nice to know *which* funcargs are present in pytest_runtest_setup, even though they are not yet initialized and have gotten their values. One solution would be to manually mark all live_server test-cases with transaction_test_case, but that is a bit too much typing for my taste: :) @pytest.mark.transaction_test_case def test_foo(live_server): pass Is there any way to see what funcargs are specified from within pytest_runtest_setup? If not, is there another way I should approach this problem? Or should I just give up and decorate all live server tests with @pytest.mark.transaction_test_case ? Best regards/Andreas (I am trying to make a complete pytest-django package, I have forked an old package, put it on PyPI and added some docs:https://github.com/pelme/pytest_django , I will post an announcement here later when it has seen some more progress!)

2 3