Mailman 3 September 2009 - pytest-dev

[py-dev] py.test : setup / teardown at the directory level
by Philippe Fremy April 16, 2010

April 16, 2010

Hi, I was wondering if there is a possibility to have or emulate setup/teardown method for an entire directory of tests ? I have an expensive setup/teardown method, which I share through about 10 modules, each with about 20 tests. I would save time if I could do the setup/teardown just for that directory. cheers, Philippe

3 9

[py-dev] proposal: chaining pytest_generate_tests calls
by Ronny Pfannschmidt Sept. 29, 2009

Sept. 29, 2009

Hi, after some refactoring in the tests for the new serializer and some chat with Benjamin it got appearant that some form of chaining the pytest_generate_tests is helpfull and necessart. Since there are various details lurking around, this is a initial try to collect the needs for propperly chaining generate_tests calls. I will handle each aspect in a separate section. For each aspect i will add all items i currenly consider intresting/usefull, that might be incomplete and/or more than reasonable. Necessary Scopes ---------------- conftest/plugin Required to allow comfortable whole-project generators package/module the same goes for sub-groups of the tests functions doing special cases at the module level hook tends to be a mess see the current serializer tests for reasons Additional dimensions of variation that could proof usefull ------------------------------------------------------------ funcargs choose test generators based on the arguments a function explicitly takes, implicitly used funcargs via request.getfuncargvalue cant be considered there * marks using decorators to add values and the way to add them to the call Chaining order -------------- conftest plugin -> package -> subpackage -> module -> function building the test id's ------------------------- for just chaining the tests one can simply append to a tuple of id's for each successive add_call invokation per hook if variation on funcargs is considered one could show those like additional keyword parameters funcarg generators shouldn't support chaining themself, just use the closest matching test generator dealing with the param argument of addcall ------------------------------------------- * provide the value of the most close scope to request objecs * previous values of params could be accessible via linking to the precedessor of the current call or by providing a list ordered by scope * for funcarg variation it might be helpfull to supple the funcarg function with the param the funcarg related generator created dealing with the funcargs argument of addcall --------------------------------------------- * values from more close scope should override vales for less close scope * warnings could be printed for name-clashes/overrides how to actually combine the generators -------------------------------------- Note: early never released versions of the generate_tests feature provided implied combinations of all matching test generators, however that was fragile and got dumped for 'match most closest hook' i thenk we should prefer a explicit combination where for each addcall of an outer scope, the complete generate_tests function of the inner scope has to be run this results in a clean tree of invocations and better controll over the actual combinations regards Ronny Pfannschmidt

2 1

[py-dev] New issue 51 in py-trunk: there should be a way to have tests depend on the passing of other tests
by issues-noreply＠bitbucket.org Sept. 28, 2009

Sept. 28, 2009

New issue 51: there should be a way to have tests depend on the passing of other tests http://bitbucket.org/hpk42/py-trunk/issue/51/there-should-be-a-way-to-have-… RonnyPfannschmidt on Mon, 28 Sep 2009 19:55:20 +0200: Description: a good example would be something like the execnet serializer tests testing the serializer on different python versions needing gateways to work 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 50 in py-trunk: cached_setup needs to cache correctly
by issues-noreply＠bitbucket.org Sept. 28, 2009

Sept. 28, 2009

New issue 50: cached_setup needs to cache correctly http://bitbucket.org/hpk42/py-trunk/issue/50/cached_setup-needs-to-cache-co… holger krekel / hpk42 on Mon, 28 Sep 2009 19:49:42 +0200: Description: Ronny pointed out that cached_setup does not work how one might assume: {{{ #!python def pytest_funcarg__one(request): return request.cached_setup(lambda: 42) def pytest_funcarg__two(request): return request.cached_setup(lambda: 17) def test_hello(one, two): # one and two will both be 42! }}} this is because the 'request' object is re-used across all function argument setups and the funcarg name is not stored on it. Needs to be better document or fixed - likely adding 'funcargname' as a key is the best approach even if it complicates the implemnetation a bit. 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 49 in py-trunk: figleaf plugin cannot be used
by issues-noreply＠bitbucket.org Sept. 27, 2009

Sept. 27, 2009

New issue 49: figleaf plugin cannot be used http://bitbucket.org/hpk42/py-trunk/issue/49/figleaf-plugin-cannot-be-used Anonymous on Sun, 27 Sep 2009 19:52:02 +0200: Description: py 1.02, python 2.6, OS winxp 32 xp3 I installed py using easy_install figleaf plugin cannot be used tried py.test -F, no such option tried py.test -p figleaf, could not import plugin 'pytest_figleaf', reason: "could not import 'figleaf.annotate_html' "" -- 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] Remote Distribution
by Dj Gilcrease Sept. 27, 2009

Sept. 27, 2009

I know py.test has distributed testing already but I have been using Testswarm (a distributed javascript testing framework) for a while now and thought the idea would fit nicely with py.test. This is just me kind of brain storming the idea, so feel free to ignore me if you have no interest in this idea. Ok basic premise is: Central server for anyone to schedule test runs on Clients connect to the central server and run tests as they come in for any and all apps they meet the requirements for Goals: Eliminate the need for everyone to establish their own distributed testing network by establishing a remote distributed network where clients connect and will run tests from any app that is registered on the server. Brainstorm of requirements: Server - Needs a way for applications / libraries to register Server - Apps need a way to set dependencies, and a way to specify version for that dependency Server - Apps need a way to set the environments to test on (os version and python version) Server - Apps need a way to schedule test runs and upload the code to test against Server - Need a UI to display a test metric like http://testswarm.com/user/jquery/ Server - Needs a method of tracking available clients, and their environments Server - Needs a way to send tests to every available client that meets the environment specs for each app. Needs to keep track of the test run id for results Server - Needs to accept results back Needs to identify the run and clients environment id to make sure we can mark an environment finished for the run Server - Needs a fault catcher to reschedule a test run / environment if a remote client disconnects before it finished Server - Needs a way of removing code once all tests have been executed for a particular run, or after X days Server - Needs to ensure remote execution of apps is not possible for security Client - Needs a way to connect to the central server and keep it notified that it is still alive Client - Needs a way to receive Tests Client - Needs a way to report results back Brainstorm implementation details: modified? py.execnet for the server test dispatcher modified? py.execnet for the client test receiver Client should be command line only so it can be run as a service Web app for managing Apps and result display REsT API for scheduling test runs and uploading the required code? "py.test schedule" command?

2 2

[py-dev] how to test fallbacks for missing modules?
by Ronny Pfannschmidt Sept. 26, 2009

Sept. 26, 2009

hi, i wonder what would be a good way to test the handling of unimportable modules or fallbacks for missing modules. i don't have any initial idea on how to get started with that. Regards Ronny

2 4

[py-dev] lack of gui/async testing examples/documentation
by Ronny Pfannschmidt Sept. 26, 2009

Sept. 26, 2009

Hi, since im just right now in need to test async apps (a dbus service, and a gtk gui app with concurrency) i wanted to remind of the notorious lack of examples to figure how to do async testing propperly. Regards Ronny

1 0

Re: [py-dev] execnet / GPL licensing
by holger krekel Sept. 23, 2009

Sept. 23, 2009

Hi Massa, On Wed, Sep 16, 2009 at 10:24 +0200, Massa, Harald Armin wrote: > Just to add a viewpoint ... > > I stumbled upon this article: > > http://www.stevestreeting.com/2009/09/15/my-evolving-view-of-open-source-li… huh, this and the comments add a lot of viewpoints, not just one. > BeSD wishes, :) thanks to you and for all the feedback and advise. holger > Harald > > -- > GHUM Harald Massa > persuadere et programmare > Harald Armin Massa > Spielberger Straße 49 > 70435 Stuttgart > 0173/9409607 > no fx, no carrier pigeon > - > %s is too gigantic of an industry to bend to the whims of reality > -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

1 0

[py-dev] execnet / GPL licensing
by holger krekel Sept. 23, 2009

Sept. 23, 2009

Hi all, some of you know that i am considering licensing and general funding issues recently, see here for the current licensing status: http://codespeak.net/py/trunk/faq.html#whygpl However, i am considering releasing the execnet code under the GPL and the the rest under the LGPL. This would mean that execnet can be used in free software but not in proprietary software without getting a different license. I think execnet presents a unique and valuable approach to glueing Python interpreters and doing rapid deployment. It can particularly help with managing clouds of computers and I'd like to put more efforts into improving and extending in this area. And i'd like to tap into getting dual-licensing revenue. Which, on a side note, would flow back to me and e.g. http://merlinux.eu/people.html so we all can continue to work on great things. I am open to comments, arguments or bribes in the form of contracts for improvements :) cheers, holger Maybe also of interest to you (currently unreachable for me, though) http://www.fsf.org/licensing/licenses/why-not-lgpl.html -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

4 8