Mailman 3 April 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] ANN: pytest-couchdbkit 0.5.1
by Ronny Pfannschmidt April 17, 2012

April 17, 2012

Hello, i am sorry to have to release pytest-couchdbkit 0.5.1 so early i noticed that 0.4 broke normal testing way too late, which is fixed now 0.5.1 was necessary due to noticing a typo in MANIFEST.in right after the 0.5 release which silently dropped the tests from the release as a little gem i added support for pytest-xdist to pytest-couchdbkit, so happy parallel testing. -- Ronny pytest-couchdbkit ================= pytest-couchdbkit is a simple pytest extension that manages test databases for your couchdbkit using apps. In order to use it, you only need to set the ini option `couchdbkit_suffix` to something fitting your app. Additionally you may use `couchdbkit_backend` to select the gevent/eventlet backends. To setup couchapps before running the tests, there is the `pytest_couchdbkit_push_app(server, dbname)` hook It can be used to create a pristine database, which is replicated into each test database. The provided funcarg `couchdb` will be a freshly flushed database named `pytest_` + couchdbkit_suffix, additionally, after each test item, the database will be dumped to tmpdir.join(couchdb.dump) which is a simple file having entries in the format:: number(\d+) + "\r\n" + number bytes + "\r\n" entries are: * the db info * documents * raw attachment data following the document Attachments are ordered by name, so they can be reassigned to their metadata on loading. The dump format is meant to be human-readable. Future ------ * fs fixtures (like couchapp) * code fixtures * dump fixtures * comaring a db to sets of defined fixtures CHANGELOG ========= from 0.5 to 0.5.1 ----------------- - fix MANIFEST.in from 0.4 to 0.5 --------------- - fix breaking testruns that dont actually use it - add a lot of tests i should have done before 0.4 - add support for pytest-xdist, if a slave is detected, push_app wont be called, and dbname gets the gw id appended from 0.3 to 0.4 --------------- - add pytest_couchdbkit_push_app hook

1 0

[py-dev] ANN: pytest-couchdbkit 0.4
by Ronny Pfannschmidt April 16, 2012

April 16, 2012

Hello, I'm happy to announce the release of pytest-couchdbkit 0.4, which is the first release of the py.test couchdbkit integration i consider reasonably complete for others to use. It is available on http://pypi.python.org/pypi/pytest-couchdbkit/0.4 -- Ronny pytest-couchdbkit ================= pytest-couchdbkit is a simple pytest extension that manages test databases for your couchdbkit using apps. In order to use it, you only need to set the ini option `couchdbkit_suffix` to something fitting your app. Additionally you may use `couchdbkit_backend` to select the gevent/eventlet backends. To setup couchapps before running the tests, there is the `pytest_couchdbkit_push_app(server, dbname)` hook It can be used to create a pristine database, which is replicated into each test database. The provided funcarg `couchdb` will be a freshly flushed database named `pytest_` + couchdbkit_suffix, additionally, after each test item, the database will be dumped to tmpdir.join(couchdb.dump) which is a simple file having entries in the format:: number(\d+) + "\r\n" + number bytes + "\r\n" entries are: * the db info * documents * raw attachment data following the document Attachments are ordered by name, so they can be reassigned to their metadata on loading. The dump format is meant to be human-readable. Future ------ * fs fixtures (like couchapp) * code fixtures * dump fixtures * comaring a db to sets of defined fixtures CHANGELOG ========= from 0.3 to 0.4 --------------- - add pytest_couchdbkit_push_app hook

2 1

[py-dev] Slave fail with Interrupted system call?
by meme dough April 12, 2012

April 12, 2012

Hi, Anyone know why execnet slave would get Interrupted system call? creating slavegateway on <__main__.Popen2IO instance at 0x20fa2d8> RECEIVERTHREAD: starting to run received <Message.CHANNEL_EXEC channelid=1 len=285> received <Message.CHANNEL_DATA channelid=1 len=123> execution starts[1]: "\nimport os\npath, nice, env = channel.receive()\ execution finished sent <Message.CHANNEL_CLOSE channelid=1 > 1 sent channel close message received <Message.CHANNEL_EXEC channelid=3 len=210> 1 channel.__del__ execution starts[3]: '\nimport sys, os\nchannel.send(dict(\n executa sent <Message.CHANNEL_DATA channelid=3 len=295> execution finished sent <Message.CHANNEL_CLOSE channelid=3 > 3 sent channel close message received <Message.CHANNEL_EXEC channelid=5 len=5308> 3 channel.__del__ execution starts[5]: '"""\n This module is executed in remote subpro received <Message.CHANNEL_DATA channelid=5 len=1492> RECEIVERTHREAD Traceback (most recent call last): File "<string>", line 622, in _thread_receiver File "<string>", line 802, in load File "<string>", line 86, in read IOError: [Errno 4] Interrupted system call RECEIVERTHREAD entering finalization RECEIVERTHREAD leaving finalization sent <Message.CHANNEL_DATA channelid=5 len=451> sent <Message.CHANNEL_DATA channelid=5 ('collectionstart', {})> sent <Message.CHANNEL_DATA channelid=5 len=115> sent <Message.CHANNEL_DATA channelid=5 len=163> sent <Message.CHANNEL_DATA channelid=5 len=244> sent <Message.CHANNEL_DATA channelid=5 len=53> execution finished :)

1 0

[py-dev] OpenStack
by Brack, Laurent P. April 1, 2012

April 1, 2012

Forking from the [py-dev] pytest-timeout 0.2 e-mail thread. > I am interested in OpenStack but you can you detail a bit more of what > you want to achieve? I have attached a rough diagram of what we are building internally (hopefully it will not be filtered out). About a year ago, we attended a presentation on OpenStack (when it was still driven by Anso Labs before they got acquired by Rackspace). We were (and are) currently using a private cloud (VMWare) but contemplated the idea of scaling up to public clouds. Problem we had was that we had to develop custom code for each cloud vendor whether Amazon EC2, Penguin, VMWare, etc. so OpenStack was really a viable path to not lock ourselves in with a given vendor. While a bulk of our tests require embedded devices (in which case virtualization makes little sense) a good chunk can be run on standard workstations (all OS flavors) and in this case it only makes sense to move to a virtual environment. PyTest combined with xdist was the dream come true as we could focus on developing tests meant to run on a single machine and later seamlessly parallelize their execution. There is nothing new here. We were thinking of writing a plugin to xdist (cxdist - c for cloud) that would interface with OpenStack, using the pytest_xdist_setupnodes and pytest_configure_node hooks. In those hooks, the plugin would provision the machine (via OpenStack) and then make xdist believe that it is dealing with physical slaves. Finally at the end of the run, we would teardown the slaves, leaving resources for other tests to run. We have not started yet on this as scalability is not an issue but this is our plan. As the diagram shows, the read boxes are plugins we intend to release to the open source community. Our teams write a lot of "data driven tests" (testing various AV codecs with different configuration parameters using very similar verification procedure) and as a result we make heavy use of funcargs. The pytest_testlink plugin is very similar to the pytest Case Conductor plugin from the Mozilla folks (http://blargon7.com/2012/01/case-conductor-pytest-plugin-proposal/) but interacts with TestLink (teamst.org in which we are currently involved in - improving performance of web services etc.) as opposed to Case Conductor. However in addition to linking a test case ID to a given python test, we have implemented a simple mechanism to generate test cases from what we called Test Description Records. Those are currently stored in excel spreadsheets but will be store in TestLink as test case properties. The object injection is done automatically by the plugin using a custom marker indicating which function argument shall be used for TDR injection as well as correlating TDR with parametrized test functions. The point is that by using the funcarg feature offered by pytest, we can generate tremendous amount of test cases with little effort and this will require scalability and use of virtualization over time. Sorry for the long description, but I wanted to give a complete overview to help comprehend where we are going. Our plan is to eventually release all this to the open source community (when we think the plugins are mature and robust enough). If other people have a need/interest for those plugins (some of them are not illustrated), I would be more than happy to accelerate this process (getting approval from our Open Source Board). Since pytest_cxdist doesn't exist, this could be open source from the get go. Best Laurent

2 3