From nicoddemus at gmail.com Mon Oct 3 18:37:14 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 03 Oct 2016 22:37:14 +0000 Subject: [pytest-dev] How to repeat tests with a setup-action before each repitition In-Reply-To: References: Message-ID: Hello Emil, On Fri, Sep 30, 2016 at 6:26 PM Emil Petersen emil.petersen at thalmic.com wrote: I am looking to repeat some of the tests in my test suite, and want to call a certain action before each repetition. To be clear, I want to: 1) First, run all the tests marked with repeat, as-is 2) Then, take a specific action, in this case rebooting a device 3) Then, repeat each test marked with repeat 4) Then, repeat steps 2-3 the amount of times specified. Using the above as an example, I want to run test_something and test_something_else, then expensive_setup, then the two tests again, then expensive_setup, etc. So only one call to expensive_setup for each run including test_something() and test_something_else() What would be a sensible way to go about this? I might not full fill all your requirements, but here are some ideas: You can use a parametrized fixture which calls the expensive setup after its first instantiation: def test_something(device): check_something == last_result_from_file() def test_something_else(device): something_else() @pytest.fixture(params=[0, 1, 2, 3]def expensive_setup(request): device = Device('uri_to_device') device.connect() if request.param > 0: device.reboot() return device As an addendum, it is ideal if each test is only reported as -one- test, rather than one test being generated for each run. That?s not so simple, you will probably have to override the terminal plugin and implement your own pytest_runtest_logreport to accumulate reports. I suspect this is more trouble than it is worth. Ideally, if any one call to the functions ends up generating a failure or error, it would be able to fail, and abort any attempts at subsequently running (I.e. failures should be final). For that you can use --max-fail or -x, which will cause pytest to stop at the first failure. In case you?re curious about why the tests need to be repeated, it?s to hunt for race conditions, and other failures which may occur sometimes. You might want to take a look at pytest-repeat , which was created to help find intermittent failures. Hope that helps! Cheers, Bruno; ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil.petersen at thalmic.com Tue Oct 4 11:58:01 2016 From: emil.petersen at thalmic.com (Emil Petersen) Date: Tue, 4 Oct 2016 11:58:01 -0400 Subject: [pytest-dev] How to repeat tests with a setup-action before each repitition In-Reply-To: References: Message-ID: <15A2A111-0293-4F37-A9A3-CA9D84639920@thalmic.com> Hi Bruno, Thank you for your time, and for the suggestions. Unfortunately they don?t address the core pain I am trying to solve - namely that expensive_setup is, well, expensive, and that running it for every test will in the long run be unacceptable. The difference is having to run it exactly the amount of times I?ve specified, vs that amount, times the count of tests who are marked repeat. If it repeats 100 times, say, you can easily see how badly this would scale with just a few dozen tests. -x and?max-fail, similarly, if I understand them correctly, would stop the -rest- of the suite from running, which isn?t my intent. Rather, I want the rest of the tests to run, only wanting to consolidate the repeated tests into one result per test, with one failure counting as the whole chain of repetition. But I think I can solve this with pytest_runtest_logreport. pytest-repeat, as far as I could tell from the documentation, repeats every test. That isn?t my intent, as only those I will explicitly mark provide extra value being re-run. The next thing I?m going to try is to make some sort of shared resource, probably using some resources for threading, and making each test ?wait? for the resource to be freed. Then, maybe, from the ?tell me when resource becomes free? function, I can wait for everyone to be waiting, then reboot, then release the lock. Hopefully that?ll work. Kind regards, -- Emil Petersen | Software Test Engineer T: 1-888-777-2546 x692 <> E: emil.petersen at thalmic.com > On Oct 3, 2016, at 6:37 PM, Bruno Oliveira wrote: > > Hello Emil, > > On Fri, Sep 30, 2016 at 6:26 PM Emil Petersen emil.petersen at thalmic.com wrote: > > > I am looking to repeat some of the tests in my test suite, and want to call a certain action before each repetition. To be clear, I want to: > > 1) First, run all the tests marked with repeat, as-is > 2) Then, take a specific action, in this case rebooting a device > 3) Then, repeat each test marked with repeat > 4) Then, repeat steps 2-3 the amount of times specified. > > Using the above as an example, I want to run test_something and test_something_else, then expensive_setup, then the two tests again, then expensive_setup, etc. So only one call to expensive_setup for each run including test_something() and test_something_else() > > What would be a sensible way to go about this? > > > I might not full fill all your requirements, but here are some ideas: > > You can use a parametrized fixture which calls the expensive setup after its first instantiation: > > def test_something(device): > check_something == last_result_from_file() > > def test_something_else(device): > something_else() > > @pytest.fixture(params=[0, 1, 2, 3] > def expensive_setup(request): > device = Device('uri_to_device') > device.connect() > if request.param > 0: > device.reboot() > return device > > > As an addendum, it is ideal if each test is only reported as -one- test, rather than one test being generated for each run. > > > That?s not so simple, you will probably have to override the terminal plugin and implement your own pytest_runtest_logreport to accumulate reports. > > I suspect this is more trouble than it is worth. > > > > Ideally, if any one call to the functions ends up generating a failure or error, it would be able to fail, and abort any attempts at subsequently running (I.e. failures should be final). > > > For that you can use --max-fail or -x, which will cause pytest to stop at the first failure. > > > > In case you?re curious about why the tests need to be repeated, it?s to hunt for race conditions, and other failures which may occur sometimes. > > > You might want to take a look at pytest-repeat , which was created to help find intermittent failures. > > Hope that helps! > > Cheers, > Bruno; > -- ---- CONFIDENTIALITY NOTICE: This communication, and any attachments thereto, is confidential and intended solely for use by the recipient(s) named above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpfannsc at redhat.com Tue Oct 4 13:18:27 2016 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Tue, 4 Oct 2016 19:18:27 +0200 Subject: [pytest-dev] ANN: pytest-external-blockers - prototype released Message-ID: Hi all, i'm happy to announce the release of pytest-external-blockers [0] it was created in order to be able to semantically track for what reasons a test was skipped a normal `pytest.skip` doesn't offer a semantic difference between "skipped for a local reason" and "skipped for a external reason" so we choose to pick a new verb. that way every dynamic "skip" that happens for a external reason (like database down, known to be broken tests, unavailable network service) can be identified. In future i want to extend this concept to xfail. I'm hoping for some harsh critique :) [0] https://github.com/RonnyPfannschmidt/pytest-external-blockers https://pypi.python.org/pypi/pytest-external-blockers -- Ronny -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Tue Oct 11 15:50:22 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Tue, 11 Oct 2016 21:50:22 +0200 Subject: [pytest-dev] creating pytest-boxed and removing boxed from xdist Message-ID: Hi everyone, in order to enable refactoring xdist, i took out the boxed code and started to put it into https://github.com/pytest-dev/pytest-boxed the plan is to make the next release of xdist dependent on it, then phase it out as dependency later -- Ronny From oliver.schoenborn at gmail.com Tue Oct 11 18:46:12 2016 From: oliver.schoenborn at gmail.com (oliver) Date: Tue, 11 Oct 2016 22:46:12 +0000 Subject: [pytest-dev] creating pytest-boxed and removing boxed from xdist In-Reply-To: References: Message-ID: Is there any plan to port boxed and xdist plugins to Windows? What are the issues that have prevented implementation from happening (or happening sooner, if planned)? On Tue, Oct 11, 2016, 15:57 Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > Hi everyone, > > in order to enable refactoring xdist, > i took out the boxed code and started to put it into > > https://github.com/pytest-dev/pytest-boxed > > the plan is to make the next release of xdist dependent on it, then > phase it out as dependency later > > -- Ronny > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -- Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Tue Oct 11 18:57:40 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 11 Oct 2016 22:57:40 +0000 Subject: [pytest-dev] creating pytest-boxed and removing boxed from xdist In-Reply-To: References: Message-ID: On Tue, Oct 11, 2016 at 7:46 PM oliver wrote: > Is there any plan to port boxed and xdist plugins to Windows? What are the > issues that have prevented implementation from happening (or happening > sooner, if planned)? > Hey, The boxed implementation depends on os.fork, which is not available on Windows. But except for --boxed, xdist works just fine on Windows. A common question is "Why not use a sub-process instead?" One of the reasons is that is not really simple to serialize and send the collected tests on a wire to a subprocess, so xdist uses fork to spawn a child sharing the same memory and control it from master in case it crashes. I think I read someone mention that the "slave restart" functionality is considered a good enough replacement for boxed, which is the reason why it is being phased out. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.schoenborn at gmail.com Tue Oct 11 20:16:22 2016 From: oliver.schoenborn at gmail.com (oliver) Date: Wed, 12 Oct 2016 00:16:22 +0000 Subject: [pytest-dev] creating pytest-boxed and removing boxed from xdist In-Reply-To: References: Message-ID: On Tue, Oct 11, 2016, 18:57 Bruno Oliveira wrote: > On Tue, Oct 11, 2016 at 7:46 PM oliver > wrote: > > Is there any plan to port boxed and xdist plugins to Windows? What are the > issues that have prevented implementation from happening (or happening > sooner, if planned)? > > > Hey, > > The boxed implementation depends on os.fork, which is not available on > Windows. But except for --boxed, xdist works just fine on Windows. > > A common question is "Why not use a sub-process instead?" One of the > reasons is that is not really simple to serialize and send the collected > tests on a wire to a subprocess, so xdist uses fork to spawn a child > sharing the same memory and control it from master in case it crashes. > Thanks for info. Just trying to see if I could help with this... "send the collected tests... to a subprocess" and "control [subprocess] from master in case it crashes" are not that difficult on Windows, is there some deeper problem or other requirement that is headache? I think I read someone mention that the "slave restart" functionality is > considered a good enough replacement for boxed, > This covers recovery after a test crashes the suite, but AFAICT it doesn't support isolating a test from all the other tests so no sharing of memory space, or to test mutually exclusive import configurations etc, does it? Oliver > -- Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Wed Oct 12 01:43:33 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Wed, 12 Oct 2016 07:43:33 +0200 Subject: [pytest-dev] creating pytest-boxed and removing boxed from xdist In-Reply-To: References: Message-ID: <54d391a3-2871-96df-581c-0e25bfa6af07@ronnypfannschmidt.de> On 12.10.2016 02:16, oliver wrote: > On Tue, Oct 11, 2016, 18:57 Bruno Oliveira > wrote: > > On Tue, Oct 11, 2016 at 7:46 PM oliver > > > wrote: > > Is there any plan to port boxed and xdist plugins to Windows? > What are the issues that have prevented implementation from > happening (or happening sooner, if planned)? > > > Hey, > > The boxed implementation depends on os.fork, which is not > available on Windows. But except for --boxed, xdist works just > fine on Windows. > > A common question is "Why not use a sub-process instead?" One of > the reasons is that is not really simple to serialize and send the > collected tests on a wire to a subprocess, so xdist uses fork to > spawn a child sharing the same memory and control it from master > in case it crashes. > > > Thanks for info. Just trying to see if I could help with this... "send > the collected tests... to a subprocess" and "control [subprocess] > from master in case it crashes" are not that difficult on Windows, is > there some deeper problem or other requirement that is headache? its halfway implemented as slave-restart, the main problem is that the current implementation grew into spaghetti, since it implements state-machines in a totally non-formal way thus has impossible to debug bugs > > I think I read someone mention that the "slave restart" > functionality is considered a good enough replacement for boxed, > > > This covers recovery after a test crashes the suite, but AFAICT it > doesn't support isolating a test from all the other tests so no > sharing of memory space, or to test mutually exclusive import > configurations etc, does it? all that's needed for full isolation is to instruct each slave to run and teardown exactly one test in fact the isolation will be much better than what we currently have (fork for runtestprotocol) i just absolutely want to avoid having to implement that flow on top of the current code-base -- Ronny > Oliver > > -- > Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Oct 13 19:30:29 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 13 Oct 2016 23:30:29 +0000 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: References: Message-ID: Hey Ronny, On Wed, Sep 7, 2016 at 10:45 AM Ronny Pfannschmidt wrote: > such a flat namespace really doesn't scale > > as such i would like to propose having marker types and objects as > importable objects > I'm not against adding support for it, but I wouldn't change it to be the "recommended way" to do it: breaks backward compatibility and having more than one way to do it might be confusing to users. Perhaps mentioning it in some advanced session in the docs. > import pytest > from pytest_bugzilla import Blocker > > > @pytest.mark(Blocker(123)) > def test_fun(): > pass > What do you think would be the requirements for the Blocker object? Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.schulze at gmx.net Wed Oct 19 04:28:00 2016 From: florian.schulze at gmx.net (Florian Schulze) Date: Wed, 19 Oct 2016 10:28:00 +0200 Subject: [pytest-dev] pytest-warnings RFC Message-ID: <3AB2FF86-C5FA-40F9-8E52-387A71D70628@gmx.net> Hi! There is an open PR on pytest-warnings: https://github.com/fschulze/pytest-warnings/pull/2 Because we plan to incorporate pytest-warnings into pytest at some point, I'd like to get some feedback on it. Especially the naming of things. Otherwise we may have to rename things when merging. Regards, Florian Schulze From flub at devork.be Wed Oct 19 11:01:06 2016 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 19 Oct 2016 16:01:06 +0100 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: References: Message-ID: On 7 September 2016 at 10:38, Ronny Pfannschmidt wrote: > Hi all, > > while trying to turn various internal markers of a work project > into public plugins, i noticed a very plain problems - different other > plugins used the same generic marker name for different purposes/intents > > such a flat namespace really doesn't scale > > as such i would like to propose having marker types and objects as > importable objects > > for example > > import pytest > from pytest_bugzilla import Blocker > > @pytest.mark(Blocker(123)) > def test_fun(): > pass > > that way we can do both, reuse python name-spacing *and* use more meaningful > objects for markings I'm rather lukewarm for this proposal to be honest. We already have an API which allows creating of mark objects for later re-use: blocker = pytest.mark.bugzilla_blocker @blocker def test_fun(): pass So instead of changing the way way pytest.mark behaves I think it might be more interesting to look at alternative ways of creating marker objects. E.g. if you could do: # pytest_bugzilla.py class Blocker(pytest.MarkerObject): def __init__(self, n): pass # test_fun.py from pytest_bugzilla import Blocker @Blocker(123) def test_fun(): pass Then you can still import your marker and you also get more strict namespacing since you created a unique object in your module. But the benefit is that from the point of view of using markers not much has changed. There's just a new way of creating markers. What do you reckon about such an approach? Finally, and I only just remembered, Holger has some lingering code somewhere which does something like: @pytest.marker def blocker(n): return {'issue no': int(n)} # or whatever object you want your marker to be @pytest.mark.blocker(123) def test_fun(): pass This uses symmetry with how we create fixtures, which is nice. But it does not solve the namespacing issue, which to some extend also exists in fixtures. Just brainstorming to add something namespace like to that would be: @pytest.marker(ns='bugzilla') def blocker(n): return int(n) @pytest.mark.bugzilla.blocker(123) def test_fun(): pass I admit this does not re-use the python module namespaces, which is probably a downside. Floris From flub at devork.be Wed Oct 19 11:21:46 2016 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 19 Oct 2016 16:21:46 +0100 Subject: [pytest-dev] ANN: pytest-external-blockers - prototype released In-Reply-To: References: Message-ID: On 4 October 2016 at 18:18, Ronny Pfannschmidt wrote: > Hi all, > > i'm happy to announce the release of pytest-external-blockers [0] > it was created in order to be able to semantically track for what reasons a > test was skipped > > a normal `pytest.skip` doesn't offer a semantic difference between "skipped > for a local reason" and "skipped for a external reason" > > so we choose to pick a new verb. > that way every dynamic "skip" that happens for a external reason (like > database down, known to be broken tests, unavailable network service) can be > identified. > > In future i want to extend this concept to xfail. > > I'm hoping for some harsh critique :) This plugin is essentially trying to extend the possible outcomes, but it needs to piggyback the skip exception for integration with the core test running logic? It would be nice if you could subclass the exception from a more generic pytest.OutcomeException or so instead. Otherwise I think I don't dislike what the plugin itself does too much ;-) Floris From opensource at ronnypfannschmidt.de Thu Oct 20 03:07:47 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Thu, 20 Oct 2016 09:07:47 +0200 Subject: [pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects In-Reply-To: <7ba0be4b-2161-ac9e-a77f-3e9840cdec87@ronnypfannschmidt.de> References: <7ba0be4b-2161-ac9e-a77f-3e9840cdec87@ronnypfannschmidt.de> Message-ID: <6948da6c-05f0-67e3-ac4c-47f1666ec8b8@ronnypfannschmidt.de> forwarding as i send it with the wrong sender address -------- Forwarded Message -------- Subject: Re: [pytest-dev] Proposal: python namespacign for markings/marker objects Date: Wed, 19 Oct 2016 17:24:32 +0200 From: Ronny Pfannschmidt To: Floris Bruynooghe , pytest-dev On 19.10.2016 17:01, Floris Bruynooghe wrote: > On 7 September 2016 at 10:38, Ronny Pfannschmidt wrote: >> Hi all, >> >> while trying to turn various internal markers of a work project >> into public plugins, i noticed a very plain problems - different other >> plugins used the same generic marker name for different purposes/intents >> >> such a flat namespace really doesn't scale >> >> as such i would like to propose having marker types and objects as >> importable objects >> >> for example >> >> import pytest >> from pytest_bugzilla import Blocker >> >> @pytest.mark(Blocker(123)) >> def test_fun(): >> pass >> >> that way we can do both, reuse python name-spacing *and* use more meaningful >> objects for markings > I'm rather lukewarm for this proposal to be honest. We already have > an API which allows creating of mark objects for later re-use: > > blocker = pytest.mark.bugzilla_blocker > > @blocker > def test_fun(): > pass > > So instead of changing the way way pytest.mark behaves I think it > might be more interesting to look at alternative ways of creating > marker objects. E.g. if you could do: > > # pytest_bugzilla.py > class Blocker(pytest.MarkerObject): > def __init__(self, n): > pass > > # test_fun.py > from pytest_bugzilla import Blocker > > @Blocker(123) > def test_fun(): > pass > Then you can still import your marker and you also get more strict > namespacing since you created a unique object in your module. But the > benefit is that from the point of view of using markers not much has > changed. There's just a new way of creating markers. > > What do you reckon about such an approach? The main reason why i introduced the separation between objects and marking was to prevent a damn unreasonable mess. The objects that are the metadata put onto a function/object should be completely unaware of the py.test marking functionality, this is basics of separation of concern and prevents spaghetti behavior (like MarkInfo vs Markdecorator leaking into item.keywords and creating a fun painful mess) > > Finally, and I only just remembered, Holger has some lingering code > somewhere which does something like: > > @pytest.marker > def blocker(n): > return {'issue no': int(n)} # or whatever object you want your marker to be > > @pytest.mark.blocker(123) > def test_fun(): > pass fixtures and markers are not symmetric and i don't see a reason to make them be just for looking similar, currently they are *completely* different , and i think that bringing them closer to look more nice will make things MUCH worse. they are belonging to different categories of "things" with completely different desired behaviours. > This uses symmetry with how we create fixtures, which is nice. But it > does not solve the namespacing issue, which to some extend also exists > in fixtures. Just brainstorming to add something namespace like to > that would be: > > @pytest.marker(ns='bugzilla') > def blocker(n): > return int(n) > > @pytest.mark.bugzilla.blocker(123) > def test_fun(): > pass > > I admit this does not re-use the python module namespaces, which is > probably a downside. > i am strongly opposed to inventing a own name-spacing mechanism there, it would be another mess like the marker transfer, or the yield tests execute test code at collection time messes -- Ronny > Floris > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Thu Oct 20 03:08:14 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Thu, 20 Oct 2016 09:08:14 +0200 Subject: [pytest-dev] Fwd: Re: ANN: pytest-external-blockers - prototype released In-Reply-To: <73ddfc78-48bf-96bf-f8a7-6c756d69d6b7@ronnypfannschmidt.de> References: <73ddfc78-48bf-96bf-f8a7-6c756d69d6b7@ronnypfannschmidt.de> Message-ID: forwarding as i send it with the wrong sender address -------- Forwarded Message -------- Subject: Re: [pytest-dev] ANN: pytest-external-blockers - prototype released Date: Wed, 19 Oct 2016 17:27:42 +0200 From: Ronny Pfannschmidt To: Floris Bruynooghe , Ronny Pfannschmidt CC: pytest-dev On 19.10.2016 17:21, Floris Bruynooghe wrote: > On 4 October 2016 at 18:18, Ronny Pfannschmidt wrote: >> Hi all, >> >> i'm happy to announce the release of pytest-external-blockers [0] >> it was created in order to be able to semantically track for what reasons a >> test was skipped >> >> a normal `pytest.skip` doesn't offer a semantic difference between "skipped >> for a local reason" and "skipped for a external reason" >> >> so we choose to pick a new verb. >> that way every dynamic "skip" that happens for a external reason (like >> database down, known to be broken tests, unavailable network service) can be >> identified. >> >> In future i want to extend this concept to xfail. >> >> I'm hoping for some harsh critique :) > This plugin is essentially trying to extend the possible outcomes, but > it needs to piggyback the skip exception for integration with the core > test running logic? It would be nice if you could subclass the > exception from a more generic pytest.OutcomeException or so instead. > Otherwise I think I don't dislike what the plugin itself does too much > ;-) that simply isn't/wasn't exposed at the time also the py.test internals are completely riddled with implicit expectations about outcomes, so much that it is scary i'd love to be able to spell things more granular in different manners as well -- Ronny > Floris > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Thu Oct 20 03:17:12 2016 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 20 Oct 2016 09:17:12 +0200 Subject: [pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects In-Reply-To: <6948da6c-05f0-67e3-ac4c-47f1666ec8b8@ronnypfannschmidt.de> References: <7ba0be4b-2161-ac9e-a77f-3e9840cdec87@ronnypfannschmidt.de> <6948da6c-05f0-67e3-ac4c-47f1666ec8b8@ronnypfannschmidt.de> Message-ID: <20161020071712.gsyadytczn4cbioi@tonks> * Ronny Pfannschmidt [2016-10-20 09:07:47 +0200]: > > Finally, and I only just remembered, Holger has some lingering code > > somewhere which does something like: > > > > @pytest.marker > > def blocker(n): > > return {'issue no': int(n)} # or whatever object you want your marker to be > > > > @pytest.mark.blocker(123) > > def test_fun(): > > pass > fixtures and markers are not symmetric and i don't see a reason to make > them be > just for looking similar, currently they are *completely* different , > and i think that bringing them closer to look more nice will make things > MUCH worse. > they are belonging to different categories of "things" with completely > different desired behaviours. Then don't think of them like fixtures - but markers are essentially *functions*. They have arguments and keyword arguments, and currently everything defining a marker with arguments has to do the parsing/validating by itself. Holger's proposal seemed to clean this up and make things a lot easier. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From opensource at ronnypfannschmidt.de Thu Oct 20 03:37:23 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Thu, 20 Oct 2016 09:37:23 +0200 Subject: [pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects In-Reply-To: <20161020071712.gsyadytczn4cbioi@tonks> References: <7ba0be4b-2161-ac9e-a77f-3e9840cdec87@ronnypfannschmidt.de> <6948da6c-05f0-67e3-ac4c-47f1666ec8b8@ronnypfannschmidt.de> <20161020071712.gsyadytczn4cbioi@tonks> Message-ID: <1c6a9b13-29d4-6ac5-5394-b603018d38de@ronnypfannschmidt.de> On 20.10.2016 09:17, Florian Bruhin wrote: > * Ronny Pfannschmidt [2016-10-20 09:07:47 +0200]: >>> Finally, and I only just remembered, Holger has some lingering code >>> somewhere which does something like: >>> >>> @pytest.marker >>> def blocker(n): >>> return {'issue no': int(n)} # or whatever object you want your marker to be >>> >>> @pytest.mark.blocker(123) >>> def test_fun(): >>> pass >> fixtures and markers are not symmetric and i don't see a reason to make >> them be >> just for looking similar, currently they are *completely* different , >> and i think that bringing them closer to look more nice will make things >> MUCH worse. >> they are belonging to different categories of "things" with completely >> different desired behaviours. > Then don't think of them like fixtures - but markers are essentially > *functions*. They have arguments and keyword arguments, and currently > everything defining a marker with arguments has to do the > parsing/validating by itself. Holger's proposal seemed to clean this > up and make things a lot easier. from my pov thats **completely** wrong , a marker is an *object carrying metadata* currently we use a own mechanism to make them, and a own mechanism to validate them and we don't even pass them correctly to a test item (and neither can we without intentionally breaking the current apis) from my pov we are just creating useless code with error potential if we don't just make them plain simple objects holgers proposal creates a whole name-spacing and parsing layer for virtually no added benefit over just having a class and it carries a certain guarantee for later issues literally every single time we did something like that it ended with bugs that stayed in for 5+ years because nobody could fix them in reasonable time without breaking the api sometimes it even was completely impossible to fix -- Ronny > Florian > > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Thu Oct 20 03:40:06 2016 From: holger at merlinux.eu (holger krekel) Date: Thu, 20 Oct 2016 09:40:06 +0200 Subject: [pytest-dev] Fwd: Re: Proposal: python namespacign for markings/marker objects In-Reply-To: <6948da6c-05f0-67e3-ac4c-47f1666ec8b8@ronnypfannschmidt.de> References: <7ba0be4b-2161-ac9e-a77f-3e9840cdec87@ronnypfannschmidt.de> <6948da6c-05f0-67e3-ac4c-47f1666ec8b8@ronnypfannschmidt.de> Message-ID: <20161020074006.GQ4522@merlinux.eu> Hey Ronny, On Thu, Oct 20, 2016 at 09:07 +0200, Ronny Pfannschmidt wrote: > forwarding as i send it with the wrong sender address I find it better to send a wrongly-sent mail afresh (copy+paste) than forwarding because this forwarding looses threading-info. > > Finally, and I only just remembered, Holger has some lingering code > > somewhere which does something like: > > > > @pytest.marker > > def blocker(n): > > return {'issue no': int(n)} # or whatever object you want your marker to be > > > > @pytest.mark.blocker(123) > > def test_fun(): > > pass > fixtures and markers are not symmetric and i don't see a reason to make > them be the similarity IMO would mostly be that both fixtures and markers use functions. Currently markers require non-trivial parsing code for arguments. Whereas for the above example if you have: @pytest.mark.blocker(n=138) it would work because "pytest.mark.blocker(...)" invokes "blocker(...)" and parsing of arguments including kw-arguments works naturally. By contrast, today you have to parse "markerinfo.kwargs" and "markerinfo.args" yourself and few plugins do it correctly. Moreover, by forcing all marker instantiation to go through a registered function we have a single normalizing source of documentation. We can take the marker function's docstring and inspect the arguments. The current documentation for markers ("pytest --markers") is often not in sync with implementation. holger From holger at merlinux.eu Thu Oct 20 04:56:17 2016 From: holger at merlinux.eu (holger krekel) Date: Thu, 20 Oct 2016 10:56:17 +0200 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: References: Message-ID: <20161020085617.GR4522@merlinux.eu> Hey Ronny, i'd like to get back to your original suggestion ... On Wed, Sep 07, 2016 at 11:38 +0200, Ronny Pfannschmidt wrote: > Hi all, > > while trying to turn various internal markers of a work project > into public plugins, i noticed a very plain problems - different other > plugins used the same generic marker name for different purposes/intents > > such a flat namespace really doesn't scale The more plugins there are the more it causes potential clashes of marker and fixture names. We've had some discussions at the sprint about it IIRC. I suggest that whatever namespacing we come up with it should be a) backward-compatible b) work for both markers and fixtures. > as such i would like to propose having marker types and objects as > importable objects > > > for example > > > > import pytest > from pytest_bugzilla import Blocker > > > @pytest.mark(Blocker(123)) > def test_fun(): > pass > > that way we can do both, reuse python name-spacing *and* use more > meaningful objects for markings a few questions: - How would you integrate this with interactive help such as "py.test --markers"? - how would you access the Blocker marker from a hook? New API? - how would you apply it at module or class level? holger From opensource at ronnypfannschmidt.de Thu Oct 20 05:12:10 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Thu, 20 Oct 2016 11:12:10 +0200 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: <20161020085617.GR4522@merlinux.eu> References: <20161020085617.GR4522@merlinux.eu> Message-ID: <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> Hi Holger, On 20.10.2016 10:56, holger krekel wrote: > Hey Ronny, > > i'd like to get back to your original suggestion ... > > On Wed, Sep 07, 2016 at 11:38 +0200, Ronny Pfannschmidt wrote: >> Hi all, >> >> while trying to turn various internal markers of a work project >> into public plugins, i noticed a very plain problems - different other >> plugins used the same generic marker name for different purposes/intents >> >> such a flat namespace really doesn't scale > The more plugins there are the more it causes potential clashes of marker and fixture names. We've had some discussions at the sprint about it IIRC. I suggest that whatever namespacing we come up with it should be a) backward-compatible b) work for both markers and fixtures. python packages are pretty perfect for name-spacing markers, and its backward compatible as for fixture namespaces, if we base them in plain string names and continue doing so, i feel absolutely certain it will break in a messy way and it has different referencing needs than markers so making 2 different things use the same mechanism is a guarantee that we end up in a broken mess :( i'd much rather start a discussion about using different means even for fixtures, but thats for a different topic that i hope to start this weekend (and it would solve lot of massive headaches wrt getting rid of py.path.local) >> as such i would like to propose having marker types and objects as >> importable objects >> >> >> for example >> >> >> >> import pytest >> from pytest_bugzilla import Blocker >> >> >> @pytest.mark(Blocker(123)) >> def test_fun(): >> pass >> >> that way we can do both, reuse python name-spacing *and* use more >> meaningful objects for markings > a few questions: > > - How would you integrate this with interactive help such as "py.test --markers"? i see 2 sensible paths a) a new entry-point to make them discover-able b) running collection and getting a set of the used marker names > > - how would you access the Blocker marker from a hook? New API? basically a mark name is either a identifier or a type getmarker(Blocker) ->mark collection of Blocker objects this api break is needed anyway because what we have now is demonstrably broken and unusable in various situations, usage and parameters we get different kinds of objects with different behaviors > > - how would you apply it at module or class level? pytestmark = [ Blocker(123) ] > > holger > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- Ronny From nicoddemus at gmail.com Thu Oct 20 08:20:48 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 20 Oct 2016 12:20:48 +0000 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> References: <20161020085617.GR4522@merlinux.eu> <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> Message-ID: On Thu, Oct 20, 2016 at 7:12 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: On 20.10.2016 10:56, holger krekel wrote: > Hey Ronny, > > i >> while trying to turn various internal markers of a work project >> into public plugins, i noticed a very plain problems - different other >> plugins used the same generic marker name for different purposes/intents >> >> such a flat namespace really doesn't scale > The more plugins there are the more it causes potential clashes of marker and fixture names. We've had some discussions at the sprint about it IIRC. I suggest that whatever namespacing we come up with it should be a) backward-compatible b) work for both markers and fixtures. python packages are pretty perfect for name-spacing markers, and its backward compatible Perhaps we should clearly state the points of Ronny's proposal so we can have a more structured discussion. Also, I suggest we try to discuss the proposal using an example which we are all familiar with, like the "skipif" marker. This also lets us see how we could eventually replace the current marker's implementation in the core (hopefully improving them by making them easier to understand) while also maintaining backward compatibility. * Problem 1: Flat namespace for markers This seems to be the main point of Ronny's proposal, the fact that a flat namespace for markers doesn't scale, with the potential of different plugins using markers with the same name causing problems and confusion. Ronny's proposal: import and use "marker objects" from myplugin import SkipIf @pytest.mark(SkipIf(sys.platform != 'win32', reason='win32 only')) def test_foo(): pass * Problem 2: How plugins use markers and handle their arguments Currently plugins using markers have to deal with the *args and **kwargs parameters themselves, which is often messy and done incorrectly. Currently: def pytest_collection_modifyitems(items): for item in items: m = item.getmarker('skipif') condition = m.args[0] if skip.args else m.kwargs['condition'] ... If getmarker also supports a `type` as parameter, this becomes possible: def pytest_collection_modifyitems(items): for item in items: skipif = item.getmarker(SkipIf) m.condition # naturally available as an attribute ... IMO the API `item.getmarker(x)` can be kept backward compatible by accepting either a mark "global name" or a marker `type`. More on how to declare/register markers below. Some questions: 1. How to declare those markers? a) One of Ronny's suggestion is a new entry point: not entirely clear to me how it would be done. I personally don't like this idea, entry points are used to declare *plugins* only, and plugins use other mechanisms to declare fixtures, markers, hooks, etc. I don't think we should overload this. b) Another suggestion from Ronny: running collection and getting used marker names. I'm not entirely sure what this means exactly, since the original proposal doesn't use "names" at all, only the objects directly. One mechanism for declaring markers that I believe we discussed in the sprint was to provide a new hook which could be used to declare new markers. The hook would return a dict of marker names and opaque types, which could then be accessed by plugins using the current `item.getmarker(name)` API. For example, using "skipif": class SkipIf: def __init__(self, condition, *, reason=None): pass The hook would look like this: def pytest_register_markers(config): return {'skipif': SkipIf} This is similar to what Floris mentioned: @pytest.marker def skipif(condition, *, reason=None): return SkipIf(condition, reason=reason) In both cases, `@pytest.mark.skipif` would instantiate a new `SkipIf` instance with the parameters given and make it available to items using the `item.getmarker(name)` API. I really like both the hook idea as well as the `@pytest.marker` decorator as a way to improve how the current markers work because they fix the "handle *args and **kwargs" problem nicely. This of course doesn`t address the "flat namespace" problem, but I think they both can co-exist. 2. How to declare markers at the module and class level. Ronny suggests using the `pytestmark` mechanism for that, which I think works and is backward compatible. I would like to comment that marks are often used in test suites (as opposed to in plugins) to mark some tests for test selection using `-m`, for example `@pytest.mark.integration` or `@pytest.mark.units`. In this use case, the user usually doesn't pass any arguments and doesn't formally declare markers. But I think this is still compatible with the proposal so far, because `item.getmarker` in those cases could return a general `Marker(*args, **kwargs)` object when `pytest.mark.integration` is called and no "integration" marker has been registered. --- So far I think we can address both the "flat namespace" and "argument handling" aspects of markers in a compatible way, which can even be implemented and deployed separately in a backward compatible way. IMHO the discussion by email at this point is a little hard to digest and to track all points/replies/proposals. Perhaps we should move this discussion to a different venue? I propose an issue on GitHub because the main issue containing the proposal can be updated as the discussion progresses, although I'm not sure if it would be any easier to track the discussion itself. Perhaps using the Wiki would also be possible? Cheers, Bruno. as for fixture namespaces, if we base them in plain string names and continue doing so, i feel absolutely certain it will break in a messy way and it has different referencing needs than markers so making 2 different things use the same mechanism is a guarantee that we end up in a broken mess :( i'd much rather start a discussion about using different means even for fixtures, but thats for a different topic that i hope to start this weekend (and it would solve lot of massive headaches wrt getting rid of py.path.local) >> as such i would like to propose having marker types and objects as >> importable objects >> >> >> for example >> >> >> >> import pytest >> from pytest_bugzilla import Blocker >> >> >> @pytest.mark(Blocker(123)) >> def test_fun(): >> pass >> >> that way we can do both, reuse python name-spacing *and* use more >> meaningful objects for markings > a few questions: > > - How would you integrate this with interactive help such as "py.test --markers"? i see 2 sensible paths a) a new entry-point to make them discover-able b) running collection and getting a set of the used marker names > > - how would you access the Blocker marker from a hook? New API? basically a mark name is either a identifier or a type getmarker(Blocker) ->mark collection of Blocker objects this api break is needed anyway because what we have now is demonstrably broken and unusable in various situations, usage and parameters we get different kinds of objects with different behaviors > > - how would you apply it at module or class level? pytestmark = [ Blocker(123) ] > > holger > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -- Ronny _______________________________________________ pytest-dev mailing list pytest-dev at python.org https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Thu Oct 20 08:55:35 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Thu, 20 Oct 2016 14:55:35 +0200 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: References: <20161020085617.GR4522@merlinux.eu> <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> Message-ID: <1c4f63bd-da6f-d4f8-2a7d-79575afc8b8c@ronnypfannschmidt.de> HI Bruno On 20.10.2016 14:20, Bruno Oliveira wrote: > On Thu, Oct 20, 2016 at 7:12 AM Ronny Pfannschmidt > > wrote: > > > On 20.10.2016 10:56, holger krekel wrote: > > Hey Ronny, > > > > i > >> while trying to turn various internal markers of a work project > >> into public plugins, i noticed a very plain problems - > different other > >> plugins used the same generic marker name for different > purposes/intents > >> > >> such a flat namespace really doesn't scale > > The more plugins there are the more it causes potential clashes > of marker and fixture names. We've had some discussions at the > sprint about it IIRC. I suggest that whatever namespacing we come > up with it should be a) backward-compatible b) work for both > markers and fixtures. > python packages are pretty perfect for name-spacing markers, and its > backward compatible > > > Perhaps we should clearly state the points of Ronny's proposal so we > can have a more structured discussion. Also, I suggest we try to > discuss the proposal using an example which we are all familiar with, > like the "skipif" marker. This also lets us see how we could > eventually replace the current marker's implementation in the core > (hopefully improving them by making them easier to understand) while > also maintaining backward compatibility. > > * Problem 1: Flat namespace for markers > > This seems to be the main point of Ronny's proposal, the fact that a > flat namespace for markers doesn't scale, with the potential of > different plugins using markers with the same name causing problems > and confusion. > > Ronny's proposal: import and use "marker objects" > > from myplugin import SkipIf > > @pytest.mark(SkipIf(sys.platform != 'win32', reason='win32 only')) > def test_foo(): > pass > > * Problem 2: How plugins use markers and handle their arguments > > Currently plugins using markers have to deal with the *args and > **kwargs parameters themselves, which is often messy and done incorrectly. > > Currently: > > def pytest_collection_modifyitems(items): > for item in items: > m = item.getmarker('skipif') > condition = m.args[0] if skip.args else m.kwargs['condition'] > ... > > If getmarker also supports a `type` as parameter, this becomes possible: > > def pytest_collection_modifyitems(items): > for item in items: > skipif = item.getmarker(SkipIf) > m.condition # naturally available as an attribute > ... > > IMO the API `item.getmarker(x)` can be kept backward compatible by > accepting either a mark "global name" or a marker `type`. More on how > to declare/register markers below. > > Some questions: > > 1. How to declare those markers? > > a) One of Ronny's suggestion is a new entry point: not entirely clear > to me how it would be done. I personally don't like this idea, entry > points are used to declare *plugins* only, and plugins use other > mechanisms to declare fixtures, markers, hooks, etc. I don't think we > should overload this. > > b) Another suggestion from Ronny: running collection and getting used > marker names. I'm not entirely sure what this means exactly, since the > original proposal doesn't use "names" at all, only the objects directly. in my proposal the "name" of a marker would be either the current string or a type > > One mechanism for declaring markers that I believe we discussed in the > sprint was to provide a new hook which could be used to declare new > markers. The hook would return a dict of marker names and opaque > types, which could then be accessed by plugins using the current > `item.getmarker(name)` API. For example, using "skipif": > > class SkipIf: > def __init__(self, condition, *, reason=None): > pass > > The hook would look like this: > > def pytest_register_markers(config): > return {'skipif': SkipIf} > > This is similar to what Floris mentioned: > > @pytest.marker > def skipif(condition, *, reason=None): > return SkipIf(condition, reason=reason) > > In both cases, `@pytest.mark.skipif` would instantiate a new `SkipIf` > instance with the parameters given and make it available to items > using the `item.getmarker(name)` API. another important part of my proposal is, that i want to decouple from the namespace we put into pytest.mark, after all there is now a multitude of plugins that register certain markers, sometimes for *different* usages and incompatible signatures > > I really like both the hook idea as well as the `@pytest.marker` > decorator as a way to improve how the current markers work because > they fix the "handle *args and **kwargs" problem nicely. > > This of course doesn`t address the "flat namespace" problem, but I > think they both can co-exist. > > 2. How to declare markers at the module and class level. > > Ronny suggests using the `pytestmark` mechanism for that, which I > think works and is backward compatible. > > I would like to comment that marks are often used in test suites (as > opposed to in plugins) to mark some tests for test selection using > `-m`, for example `@pytest.mark.integration` or `@pytest.mark.units`. > In this use case, the user usually doesn't pass any arguments and > doesn't formally declare markers. But I think this is still compatible > with the proposal so far, because `item.getmarker` in those cases > could return a general `Marker(*args, **kwargs)` object when > `pytest.mark.integration` is called and no "integration" marker has > been registered. > > --- > > So far I think we can address both the "flat namespace" and "argument > handling" aspects of markers in a compatible way, which can even be > implemented and deployed separately in a backward compatible way. > > IMHO the discussion by email at this point is a little hard to digest > and to track all points/replies/proposals. Perhaps we should move this > discussion to a different venue? I propose an issue on GitHub because > the main issue containing the proposal can be updated as the > discussion progresses, although I'm not sure if it would be any easier > to track the discussion itself. Perhaps using the Wiki would also be > possible? > i could make a wiki page cheers, Ronny > Cheers, > Bruno. > > > as for fixture namespaces, if we base them in plain string names and > continue doing so, > i feel absolutely certain it will break in a messy way and it has > different referencing needs than markers > > so making 2 different things use the same mechanism is a guarantee > that > we end up in a broken mess :( > > i'd much rather start a discussion about using different means > even for > fixtures, > but thats for a different topic that i hope to start this weekend (and > it would solve lot of massive headaches wrt getting rid of > py.path.local) > > > >> as such i would like to propose having marker types and objects as > >> importable objects > >> > >> > >> for example > >> > >> > >> > >> import pytest > >> from pytest_bugzilla import Blocker > >> > >> > >> @pytest.mark(Blocker(123)) > >> def test_fun(): > >> pass > >> > >> that way we can do both, reuse python name-spacing *and* use more > >> meaningful objects for markings > > a few questions: > > > > - How would you integrate this with interactive help such as > "py.test --markers"? > i see 2 sensible paths > a) a new entry-point to make them discover-able > b) running collection and getting a set of the used marker names > > > > > - how would you access the Blocker marker from a hook? New API? > basically a mark name is either a identifier or a type > > getmarker(Blocker) ->mark collection of Blocker objects > > this api break is needed anyway because what we have now is > demonstrably broken and unusable > in various situations, usage and parameters we get different > kinds of > objects with different behaviors > > > > > - how would you apply it at module or class level? > pytestmark = [ Blocker(123) ] > > > > > > holger > > _______________________________________________ > > pytest-dev mailing list > > pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > -- Ronny > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Oct 20 09:14:48 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 20 Oct 2016 13:14:48 +0000 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: <1c4f63bd-da6f-d4f8-2a7d-79575afc8b8c@ronnypfannschmidt.de> References: <20161020085617.GR4522@merlinux.eu> <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> <1c4f63bd-da6f-d4f8-2a7d-79575afc8b8c@ronnypfannschmidt.de> Message-ID: Hey Ronny, On Thu, Oct 20, 2016 at 10:55 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > b) Another suggestion from Ronny: running collection and getting used > marker names. I'm not entirely sure what this means exactly, since the > original proposal doesn't use "names" at all, only the objects directly. > > in my proposal the "name" of a marker would be either the current string > or a type > I'm still not getting how that fits with the collection of *tests*... consider this module: # contents of test_foo.py from pytest_blocker import Blocker @Blocker(123) def test_foo(): pass How does pytest know that the file "test_foo" uses "Blocker", and that "Blocker" is a marker? One possible solution would be to inspect the namespace and see if any of the objects are a pytest.Mark subclass. I'm not suggesting that, just trying to illustrate what I mean by my question. another important part of my proposal is, that i want to decouple from the > namespace we put into pytest.mark, > after all there is now a multitude of plugins that register certain > markers, sometimes for *different* usages and incompatible signatures > That's the "flat namespaces" part of the discussion, if I'm understanding your proposal correctly. :) > IMHO the discussion by email at this point is a little hard to digest and > to track all points/replies/proposals. Perhaps we should move this > discussion to a different venue? I propose an issue on GitHub because the > main issue containing the proposal can be updated as the discussion > progresses, although I'm not sure if it would be any easier to track the > discussion itself. Perhaps using the Wiki would also be possible? > > i could make a wiki page > I would like to see what others think first. People might be OK with the current format, or have other suggestions. Cheers Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Thu Oct 20 10:33:26 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Thu, 20 Oct 2016 16:33:26 +0200 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: References: <20161020085617.GR4522@merlinux.eu> <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> <1c4f63bd-da6f-d4f8-2a7d-79575afc8b8c@ronnypfannschmidt.de> Message-ID: <1988ae7c-02b9-9b9a-b9a3-1a38a5739c5e@ronnypfannschmidt.de> On 20.10.2016 15:14, Bruno Oliveira wrote: > Hey Ronny, > > > On Thu, Oct 20, 2016 at 10:55 AM Ronny Pfannschmidt > > wrote: > >> b) Another suggestion from Ronny: running collection and getting >> used marker names. I'm not entirely sure what this means exactly, >> since the original proposal doesn't use "names" at all, only the >> objects directly. > in my proposal the "name" of a marker would be either the current > string or a type > > > I'm still not getting how that fits with the collection of *tests*... > consider this module: > > # contents of test_foo.py > from pytest_blocker import Blocker > > @Blocker(123) > def test_foo(): > pass > fist that usage is wrong, a *mark* object in my proposal is neither usable as decorator, nor aware of mark mechanism, it can literally be any object a *mark* is orthogonal to the process of marking, mixing those 2 concepts just creates a huge mess after collection you have the test items, those have all the markers, from the markers of test items one can infer the markers used in the collected tests -- Ronny > How does pytest know that the file "test_foo" uses "Blocker", and that > "Blocker" is a marker? One possible solution would be to inspect the > namespace and see if any of the objects are a pytest.Mark subclass. > I'm not suggesting that, just trying to illustrate what I mean by my > question. > > another important part of my proposal is, that i want to decouple > from the namespace we put into pytest.mark, > after all there is now a multitude of plugins that register > certain markers, sometimes for *different* usages and incompatible > signatures > > > That's the "flat namespaces" part of the discussion, if I'm > understanding your proposal correctly. :) > > >> IMHO the discussion by email at this point is a little hard to >> digest and to track all points/replies/proposals. Perhaps we >> should move this discussion to a different venue? I propose an >> issue on GitHub because the main issue containing the proposal >> can be updated as the discussion progresses, although I'm not >> sure if it would be any easier to track the discussion itself. >> Perhaps using the Wiki would also be possible? >> > i could make a wiki page > > > I would like to see what others think first. People might be OK with > the current format, or have other suggestions. > > Cheers > Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Thu Oct 20 10:47:41 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 20 Oct 2016 14:47:41 +0000 Subject: [pytest-dev] Proposal: python namespacign for markings/marker objects In-Reply-To: <1988ae7c-02b9-9b9a-b9a3-1a38a5739c5e@ronnypfannschmidt.de> References: <20161020085617.GR4522@merlinux.eu> <5735b450-ca38-a19e-6e47-eaa5bebf2523@ronnypfannschmidt.de> <1c4f63bd-da6f-d4f8-2a7d-79575afc8b8c@ronnypfannschmidt.de> <1988ae7c-02b9-9b9a-b9a3-1a38a5739c5e@ronnypfannschmidt.de> Message-ID: On Thu, Oct 20, 2016 at 12:33 PM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: I'm still not getting how that fits with the collection of *tests*... consider this module: # contents of test_foo.py from pytest_blocker import Blocker @Blocker(123) def test_foo(): pass fist that usage is wrong, a *mark* object in my proposal is neither usable as decorator, nor aware of mark mechanism, it can literally be any object a *mark* is orthogonal to the process of marking, mixing those 2 concepts just creates a huge mess after collection you have the test items, those have all the markers, from the markers of test items one can infer the markers used in the collected tests Oh I see, my bad. You mean this then: from pytest_blocker import Blocker @pytest.mark(Blocker(123)) def test_foo(): pass -------------- next part -------------- An HTML attachment was scrubbed... URL: From flub at devork.be Thu Oct 20 15:08:08 2016 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 20 Oct 2016 20:08:08 +0100 Subject: [pytest-dev] process for replacing yield tests with modern style In-Reply-To: References: Message-ID: On 29 August 2016 at 09:31, Ronny Pfannschmidt wrote: > Hi Chris, > > currently there is no easy/good Replacement for the use-case you outline. > the "correct" way would be a custom py.test specific collector Yeah, a custom collector is the way to go here. I agree that it was never really the correct way to do this. http://docs.pytest.org/en/latest/example/nonpython.html describes how you want to go about this I think. Regards, Floris > note that it was mostly luck this worked at all - ever since py.test > switched to collect first yield tests where semantically broken due to > running and destroying their own setupstate at collection time > > -- Ronny > > 2016-08-24 14:31 GMT+02:00 Chris Dent : >> >> >> Several years ago I developed a relative simple YAML-based way of >> doing HTTP tests. The processed turned yaml into tests and yielded >> them for pytest to collect. At the time yield was the pytest >> approved way of doing such things. That's here: >> >> https://github.com/tiddlyweb/tiddlyweb/blob/master/test/http_runner.py >> >> A few years later I took that idea and turned it into gabbi[1]. >> >> Because of local constraints (OpenStack) gabbi needed to be unittest, >> subunit and testrepository compliant and oriented. Only later, and in >> rather a hurry, did I add pytest support, using the yield style that I >> already knew. >> >> It's a bit of hacky mess because the tests are ordered >> unittest.TestCases inside a unittest.TestSuite that has fixtures in >> the scope of the TestSuite. Each yaml file becomes a TestSuite. >> For the pytest side of things, plugin code[2] uses the modifyitems >> hooks to get the fixtures working effectively. Some "driver"[3] code >> yields tests to a user-code[4] for loading the tests. >> >> I recognize that this is all a bit messy, but it does the job. Now, >> with the advent of pytest 3.x yield tests are deprecated and I'm not >> sure of the correct way to get the same behavior in modern-style. >> >> I'm aware of solutions for using yaml files themselves as the test >> files[5] but that would be a problem for existing deployed tests >> that use the style shown in [4] and would also require conftest.py >> or command line arguments and what I'm hoping to maintain is a way >> for unadorned discovery to work and for the gabbi tests to be fairly >> integrated with other tests. >> >> I can certainly migrate to the [5] style but I see this as a good >> opportunity to learn more of the details of how pytest generates >> tests and use it. Can anyone give me some pointers please? >> >> Thanks very much. >> >> [1] https://gabbi.readthedocs.io/ >> [2] https://github.com/cdent/gabbi/blob/master/gabbi/pytester.py >> [3] >> https://github.com/cdent/gabbi/blob/2bd1c803b71bd26be7822be87e249a811467b863/gabbi/driver.py#L111 >> [4] >> https://github.com/cdent/gabbi/blob/master/gabbi/tests/test_gabbits_pytest.py >> [5] >> http://docs.pytest.org/en/latest/example/nonpython.html#a-basic-example-for-specifying-tests-in-yaml-files >> >> -- >> Chris Dent ????( ? _ ??) https://anticdent.org/ >> freenode: cdent tw: @anticdent >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > > > > -- > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, > Eric Shander > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From cdent at anticdent.org Fri Oct 21 08:03:29 2016 From: cdent at anticdent.org (Chris Dent) Date: Fri, 21 Oct 2016 13:03:29 +0100 (BST) Subject: [pytest-dev] process for replacing yield tests with modern style In-Reply-To: References: Message-ID: On Thu, 20 Oct 2016, Floris Bruynooghe wrote: > On 29 August 2016 at 09:31, Ronny Pfannschmidt wrote: >> Hi Chris, >> >> currently there is no easy/good Replacement for the use-case you outline. >> the "correct" way would be a custom py.test specific collector > > Yeah, a custom collector is the way to go here. I agree that it was > never really the correct way to do this. > > http://docs.pytest.org/en/latest/example/nonpython.html describes how > you want to go about this I think. Thanks for the input. I think (if I can find the time) I can figure out what to do. Part of the complexity is that I already have the process which dynamically creates a bunch of subclasses of unittest.TestCase and want to "just use them" in pytest. The yield tests made that possible. I assume I can probably wrap those existing testcases as Items? Several years ago, when I started using pytest, the yield tests were my favorite thing about it. Super simple: push out functions that have assertions in them. That's what pytest was all about then, and it was _glorious_. In the intervening years things have become more complex. That's the nature of things. -- Chris Dent ????( ? _ ??) https://anticdent.org/ freenode: cdent tw: @anticdent From holger at merlinux.eu Sat Oct 22 13:27:11 2016 From: holger at merlinux.eu (holger krekel) Date: Sat, 22 Oct 2016 19:27:11 +0200 Subject: [pytest-dev] process for replacing yield tests with modern style In-Reply-To: References: Message-ID: <20161022172711.GA4522@merlinux.eu> Hi Chris, all, maybe there is a solution ... On Fri, Oct 21, 2016 at 13:03 +0100, Chris Dent wrote: > Several years ago, when I started using pytest, the yield tests were > my favorite thing about it. Super simple: push out functions that > have assertions in them. That's what pytest was all about then, and > it was _glorious_. In the intervening years things have become more > complex. That's the nature of things. I don't consider the discussion or development fully finished FWIW. IIRC i came up with the idea of using yield for generating tests (also thus termed "generative tests"). I liked the simplicity of generating parametrized tests with it, each nicely represented by the typical ".", the primary conceptual unit of testing. The main problem with yield-generated tests is that we call xUnit-setup/teardown methods which means we need to handle them during collection. Also it complicates the "Function" item, the builtin test item class which describes a test function, its parameters and handles it execution and failure representation. The complications could probably be reduced by separating some code out into a "YieldedFunction". But the former is a more fundamental problem and the reason why documentation for yield was mostly removed and there is a long standing recommendation to move towards the parametrize decorator or pytest_generate_tests if you need more dynamic or complex parametrization. So today we have three mechanisms for generating tests which don't require a conftest.py: - test functions using yield to generate func+param (deprecated) - @pytest.mark.parametrize-decorated test functions which are executed repeatedly with multiple argument sets. - the pytest_generate_tests(metafunc) hook which allows to parametrize function arguments or fixtures which will execute a test function repeatedly with multiple argument sets. You can use this hook in modules and classes. The decorator is btw implemented through a builtin pytest_generate_tests hook implementation and there can only be one per each module or class. So let's now get to your original example at https://github.com/tiddlyweb/tiddlyweb/blob/master/test/http_runner.py The parametrize-relevant bits read: def test_the_TESTS(): for test_data in tests: test = dict(EMPTY_TEST) test.update(test_data) yield test['name'], _run_test, test def _run_test(test): ... I think you could directly rewrite it as: def pytest_generate_tests(metafunc): if metafunc.function == test_generic: l = [] for test_data in tests: test = dict(EMPTY_TEST) test.update(test_data) l.append(test) metafunc.parametrize("test", argvalues=l, ids=ids) def test_generic(test): ... haven't tested this -- does it work for you? best, holger From rpfannsc at redhat.com Mon Oct 24 09:22:09 2016 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Mon, 24 Oct 2016 15:22:09 +0200 Subject: [pytest-dev] landing pytest.marked Message-ID: Hi everyone, i'd like to bring https://github.com/pytest-dev/pytest/pull/1921 back to attention it fixes a long-standing issue wrt putting mark on parameter values while properly separating the markers from the parameter value, it has intentionally limited scope of only dealing with marks, and provides a better solution to mark parameters, which also supports functions as parameters. the discussion on the pr itself has gone a bit too broad, and i'd like to call back to the solution of a concrete scoped problem perhaps marking the feature itself experimental -- Ronny -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: From omarkohl at gmail.com Mon Oct 24 13:04:06 2016 From: omarkohl at gmail.com (Omar Kohl) Date: Mon, 24 Oct 2016 19:04:06 +0200 Subject: [pytest-dev] T-Shirt has arrived! Message-ID: Hey, the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) Omar From nicoddemus at gmail.com Mon Oct 24 13:17:46 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Mon, 24 Oct 2016 17:17:46 +0000 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: References: Message-ID: Pics or didn't happen! :) Still waiting for mine. ^^ On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: > Hey, > > the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) > > Omar > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmi at web.de Mon Oct 24 14:29:55 2016 From: farmi at web.de (Stefan Farmbauer) Date: Mon, 24 Oct 2016 18:29:55 +0000 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: References: Message-ID: Mine arrived too. Thanks a lot. It's really cool Bruno Oliveira schrieb am Mo., 24. Okt. 2016 19:18: > Pics or didn't happen! :) > > Still waiting for mine. ^^ > > On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: > > Hey, > > the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) > > Omar > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Tue Oct 25 07:04:11 2016 From: holger at merlinux.eu (holger krekel) Date: Tue, 25 Oct 2016 13:04:11 +0200 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! Message-ID: <20161025110411.GH4522@merlinux.eu> Hi all, Florian and Regina visited last weekend, did most of the work on sending out shirts and stickers for both pytest and qutebrowser. Many thanks to Florian who spend almost a week alltogether preparing the shirts, stickers, figuring out and mostly doing all the logistics. I just brought the last packages to the post office and so everything should be on its way now. I'll leave it to him to tell about things to watch out for next time and summarize the experience. After the last costs are claimed i expect there to be around 4-5K EUR left of the original funding FYI. It's not my money so feel free to discuss how to use it. If nothing else it probably can be used for the next sprint or so. best, holger P.S.: Could someone help with setting up appveyor/windows-testing for tox's new https://github.com/tox-dev/tox repository? Would really appreciate it. From nicoddemus at gmail.com Tue Oct 25 07:45:57 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 25 Oct 2016 11:45:57 +0000 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! In-Reply-To: <20161025110411.GH4522@merlinux.eu> References: <20161025110411.GH4522@merlinux.eu> Message-ID: On Tue, Oct 25, 2016 at 9:17 AM holger krekel wrote: > Florian and Regina visited last weekend, did most of the work on sending > out shirts and stickers for both pytest and qutebrowser. Many thanks to > Florian who spend almost a week alltogether preparing the shirts, stickers, > figuring out and mostly doing all the logistics. I just brought the last > packages to the post office and so everything should be on its way now. > I'll leave it to him to tell about things to watch out for next time and > summarize the experience. > Yay nice! Thanks indeed. :) > After the last costs are claimed i expect there to be around 4-5K EUR left > of the original funding FYI. It's not my money so feel free to discuss how > to use it. If nothing else it probably can be used for the next sprint or > so. > Sounds like a good use for that money. > P.S.: Could someone help with setting up appveyor/windows-testing for > tox's new https://github.com/tox-dev/tox repository? Would really > appreciate it. > Sure, would be happy to. I will get to it later after work. Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at ronnypfannschmidt.de Tue Oct 25 09:15:06 2016 From: opensource at ronnypfannschmidt.de (Ronny Pfannschmidt) Date: Tue, 25 Oct 2016 15:15:06 +0200 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! In-Reply-To: <20161025110411.GH4522@merlinux.eu> References: <20161025110411.GH4522@merlinux.eu> Message-ID: Hi Holger, Florian and Regina, *re-send due to earlier mistake* great job, thanks to all of you who did the details and the followup i cant wait to get mine as well I would like to propose 2 potential uses for parts of the funds a) preparing and planning much better connectivity for the next sprint, the venue was fabulous but i think the bad internet connection was a tax on productivity while hacking, ensuring good connectivity independent of the venue would enable us to keep using beautiful low cost venues while not making the use of the services we grew accustomed to while developing harder than necessary b) sovereign build/ci infrastructure for both pytest* and tox* (*i* feel that travis&co are very limiting and actively prevent doing certain kinds of automation in a simple painless way,) however this is a larger topic i might not be able to address this year to begin with Given the funding volumes and used amounts, i wonder if, with the funds that are left, we could have the next sprints sponsored mostly by cooperates next time, I propose that those of us working in a company that could/should participate kick off the "paperwork mill" to see if that idea is viable. -- Ronny On 25.10.2016 13:04, holger krekel wrote: > Hi all, > > Florian and Regina visited last weekend, did most of the work on sending out shirts and stickers for both pytest and qutebrowser. Many thanks to Florian who spend almost a week alltogether preparing the shirts, stickers, figuring out and mostly doing all the logistics. I just brought the last packages to the post office and so everything should be on its way now. I'll leave it to him to tell about things to watch out for next time and summarize the experience. > > After the last costs are claimed i expect there to be around 4-5K EUR left of the original funding FYI. It's not my money so feel free to discuss how to use it. If nothing else it probably can be used for the next sprint or so. > > best, > holger > > P.S.: Could someone help with setting up appveyor/windows-testing for tox's new https://github.com/tox-dev/tox repository? Would really appreciate it. > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicoddemus at gmail.com Tue Oct 25 09:30:39 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Tue, 25 Oct 2016 13:30:39 +0000 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! In-Reply-To: References: <20161025110411.GH4522@merlinux.eu> Message-ID: Hi Ronny, On Tue, Oct 25, 2016 at 11:15 AM Ronny Pfannschmidt < opensource at ronnypfannschmidt.de> wrote: > b) sovereign build/ci infrastructure for both pytest* and tox* > (**i** feel that travis&co are very limiting and actively > prevent doing certain kinds of automation in a simple painless way,) > however this is a larger topic i might not be able to address this > year to begin with > > Could you clarify what you find limiting with Travis & AppVeyor? I ask because I'm particularly pleased on how we have AppVeyor + Travis + ReadTheDocs + Coveralls for pytest. This is an infrastructure which is free for open-source and is continually being improved. Given the funding volumes and used amounts, > i wonder if, with the funds that are left, we could have the next > sprints sponsored mostly by cooperates > next time, > > Sorry if the answer is obvious, but what do you mean by "cooperates"? Corporations? Cheers, Bruno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at the-compiler.org Tue Oct 25 09:40:33 2016 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 25 Oct 2016 15:40:33 +0200 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! In-Reply-To: <20161025110411.GH4522@merlinux.eu> References: <20161025110411.GH4522@merlinux.eu> Message-ID: <20161025134033.nckwsv2ugyw3tw5j@tonks> Hey, * holger krekel [2016-10-25 13:04:11 +0200]: > Florian and Regina visited last weekend, did most of the work on > sending out shirts and stickers for both pytest and qutebrowser. > Many thanks to Florian who spend almost a week alltogether preparing > the shirts, stickers, figuring out and mostly doing all the > logistics. I just brought the last packages to the post office and > so everything should be on its way now. And thank you Holger for your help and DoS-ing all the letter boxes you could find! :) > I'll leave it to him to tell about things to watch out for next time > and summarize the experience. I might write another blog post (like with the stickers) some day, but right now I'm quite busy with university stuff, and just really happy when I have some free time to work on qutebrowser stuff again :) I'm sure there's some room for improvements, but I'd also consider loading off the t-shirts to some "print on demand" provider like Cafepress/Spreadshirt/Zazzle which takes care of everything next time. However, that probably means worse quality for more money... I definitely underestimated the time it takes to organize all that stuff - stickers were okay, but shirts were some more work. Then again, a second time would probably work better than the first time ;) > After the last costs are claimed i expect there to be around > 4-5K EUR left of the original funding FYI. It's not my money so feel > free to discuss how to use it. If nothing else it probably can be > used for the next sprint or so. +1 for some future sprint. Can we try to do them every year or something, given enough funding? (Hopefully without wisdom teeth causing trouble next time!) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From me at the-compiler.org Tue Oct 25 09:43:08 2016 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 25 Oct 2016 15:43:08 +0200 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! In-Reply-To: References: <20161025110411.GH4522@merlinux.eu> Message-ID: <20161025134308.aqo2qbkndd2dhhmr@tonks> * Ronny Pfannschmidt [2016-10-25 15:15:06 +0200]: > Given the funding volumes and used amounts, > i wonder if, with the funds that are left, we could have the next > sprints sponsored mostly by cooperates > next time, > > I propose that those of us working in a company that could/should > participate kick off the > "paperwork mill" to see if that idea is viable. FWIW more than half of the money was already coming from companies. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From bjlockie at lockie.ca Wed Oct 26 11:49:30 2016 From: bjlockie at lockie.ca (James) Date: Wed, 26 Oct 2016 11:49:30 -0400 Subject: [pytest-dev] [TIP] instantiate class and use in all tests In-Reply-To: <20161026150157.GG4905@merlinux.eu> References: <8cd0438e-2ba5-ab74-de6c-d1c2ddf444bb@lockie.ca> <20161026150157.GG4905@merlinux.eu> Message-ID: <448fbb50-e440-2fe7-4731-9765c22a02ab@lockie.ca> On 2016-10-26 11:01 AM, holger krekel wrote: > James, as you have posted several questions already wrt to pytest may i suggest you rather subscribe and start posting to: > > https://mail.python.org/mailman/listinfo/pytest-dev > > Moreover, your examples so far contained some glitches which indicate you are not that experienced with Python yet. That's totally fine but i suggest you try to keep things as simple as you can before using all kinds of Python features. > > As to the mail below you can instantiate a class from a fixture and provide that to a test: > > class DoStuff(): > def __init__(self, a,b): > self.a=a > self.b=b > > def log(self, msg): > # do logging stuff > pass > > @pytest.fixture > def do_stuff(a, b): > return DoStuff(a, b) > > best, > holger I still can't make it work: =================================== FAILURES =================================== ______________________________ TestAclass.test_1 _______________________________ self = request = > def test_1(self,request): > ds=do_stuff(a,b) E NameError: global name 'do_stuff' is not defined testscript.py:9: NameError Is it a python error? # conftest.py import pytest @pytest.fixture(scope='module') def need_a(request): value = request.config.getoption("A") if not value: pytest.skip('test needs -A option to run') return value @pytest.fixture(scope='module') def a(request): a = pytest.config.getoption("A") return a @pytest.fixture(scope='module') def b(request): b = pytest.config.getoption("B") return b def pytest_addoption(parser): parser.addoption("--A", action="store", default=None, help="a option") parser.addoption("--B", action="store", default=None, help="b option") class DoStuff(): def __init__(self,a,b): self.a=a self.b=b def log(self,msg): # do logging stuff pass @pytest.fixture(scope='module') def do_stuff(a,b): # I tried def do_stuff(a,b,request): return DoStuff(a, b) import pytest # testscript.py @pytest.mark.incremental class TestAclass(): def test_1(self,request): ds=do_stuff(a,b) print 'inside {0}-{1} step'.format(self.__class__.__name__,request.function.__name__) print 'a={0}, b={1}'.format(ds.a,ds.b) ds.log("we are here") pass From holger at merlinux.eu Wed Oct 26 12:08:07 2016 From: holger at merlinux.eu (holger krekel) Date: Wed, 26 Oct 2016 18:08:07 +0200 Subject: [pytest-dev] [TIP] instantiate class and use in all tests In-Reply-To: <448fbb50-e440-2fe7-4731-9765c22a02ab@lockie.ca> References: <8cd0438e-2ba5-ab74-de6c-d1c2ddf444bb@lockie.ca> <20161026150157.GG4905@merlinux.eu> <448fbb50-e440-2fe7-4731-9765c22a02ab@lockie.ca> Message-ID: <20161026160807.GI4905@merlinux.eu> On Wed, Oct 26, 2016 at 11:49 -0400, James wrote: > On 2016-10-26 11:01 AM, holger krekel wrote: > > >James, as you have posted several questions already wrt to pytest may i suggest you rather subscribe and start posting to: > > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > >Moreover, your examples so far contained some glitches which indicate you are not that experienced with Python yet. That's totally fine but i suggest you try to keep things as simple as you can before using all kinds of Python features. > > > >As to the mail below you can instantiate a class from a fixture and provide that to a test: > > class DoStuff(): > > def __init__(self, a,b): > > self.a=a > > self.b=b > > def log(self, msg): > > # do logging stuff > > pass > > > > @pytest.fixture > > def do_stuff(a, b): > > return DoStuff(a, b) > > > >best, > >holger > I still can't make it work: > =================================== FAILURES > =================================== > ______________________________ TestAclass.test_1 > _______________________________ > > self = > request = > > > def test_1(self,request): > > ds=do_stuff(a,b) > E NameError: global name 'do_stuff' is not defined The "NameError" means that there is no reference to "do_stuff" in the test module. You need to list "do_stuff" in the function parameters, for example: def test_1(self, request, do_stuff): # here you can use "do_stuff" because it was passed in from # pytest by calling the "do_stuff" fixture function in # conftest.py and passing its result to test_1. holger From bjlockie at lockie.ca Wed Oct 26 12:36:56 2016 From: bjlockie at lockie.ca (James) Date: Wed, 26 Oct 2016 12:36:56 -0400 Subject: [pytest-dev] [TIP] instantiate class and use in all tests In-Reply-To: <20161026160807.GI4905@merlinux.eu> References: <8cd0438e-2ba5-ab74-de6c-d1c2ddf444bb@lockie.ca> <20161026150157.GG4905@merlinux.eu> <448fbb50-e440-2fe7-4731-9765c22a02ab@lockie.ca> <20161026160807.GI4905@merlinux.eu> Message-ID: <75be93fa-a2ff-622b-0098-ba42400e3b07@lockie.ca> On 2016-10-26 12:08 PM, holger krekel wrote: > On Wed, Oct 26, 2016 at 11:49 -0400, James wrote: >> On 2016-10-26 11:01 AM, holger krekel wrote: >> >>> James, as you have posted several questions already wrt to pytest may i suggest you rather subscribe and start posting to: >>> >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> Moreover, your examples so far contained some glitches which indicate you are not that experienced with Python yet. That's totally fine but i suggest you try to keep things as simple as you can before using all kinds of Python features. >>> >>> As to the mail below you can instantiate a class from a fixture and provide that to a test: >>> class DoStuff(): >>> def __init__(self, a,b): >>> self.a=a >>> self.b=b >>> def log(self, msg): >>> # do logging stuff >>> pass >>> >>> @pytest.fixture >>> def do_stuff(a, b): >>> return DoStuff(a, b) >>> >>> best, >>> holger >> I still can't make it work: >> =================================== FAILURES >> =================================== >> ______________________________ TestAclass.test_1 >> _______________________________ >> >> self = >> request = > >> >> def test_1(self,request): >>> ds=do_stuff(a,b) >> E NameError: global name 'do_stuff' is not defined > The "NameError" means that there is no reference to "do_stuff" in the test module. You need to list "do_stuff" in the function parameters, for example: > > def test_1(self, request, do_stuff): > # here you can use "do_stuff" because it was passed in from > # pytest by calling the "do_stuff" fixture function in > # conftest.py and passing its result to test_1. > > holger Go it I think. :-) Where does the output go though? class TestAclass(): def test_1(self,request,do_stuff): print 'inside {0}-{1} step'.format(self.__class__.__name__,request.function.__name__) print 'a={0}, b={1}'.format(do_stuff.a,do_stuff.b) do_stuff.log("we are here") pass From holger at merlinux.eu Wed Oct 26 13:17:36 2016 From: holger at merlinux.eu (holger krekel) Date: Wed, 26 Oct 2016 19:17:36 +0200 Subject: [pytest-dev] [TIP] instantiate class and use in all tests In-Reply-To: <75be93fa-a2ff-622b-0098-ba42400e3b07@lockie.ca> References: <8cd0438e-2ba5-ab74-de6c-d1c2ddf444bb@lockie.ca> <20161026150157.GG4905@merlinux.eu> <448fbb50-e440-2fe7-4731-9765c22a02ab@lockie.ca> <20161026160807.GI4905@merlinux.eu> <75be93fa-a2ff-622b-0098-ba42400e3b07@lockie.ca> Message-ID: <20161026171736.GK4905@merlinux.eu> pytest captures print/logging output during test runs and only shows it when there is a failure. Try ending a test function with "assert 0" to see what the output is. holger On Wed, Oct 26, 2016 at 12:36 -0400, James wrote: > On 2016-10-26 12:08 PM, holger krekel wrote: > >On Wed, Oct 26, 2016 at 11:49 -0400, James wrote: > >>On 2016-10-26 11:01 AM, holger krekel wrote: > >> > >>>James, as you have posted several questions already wrt to pytest may i suggest you rather subscribe and start posting to: > >>> > >>> https://mail.python.org/mailman/listinfo/pytest-dev > >>> > >>>Moreover, your examples so far contained some glitches which indicate you are not that experienced with Python yet. That's totally fine but i suggest you try to keep things as simple as you can before using all kinds of Python features. > >>> > >>>As to the mail below you can instantiate a class from a fixture and provide that to a test: > >>> class DoStuff(): > >>> def __init__(self, a,b): > >>> self.a=a > >>> self.b=b > >>> def log(self, msg): > >>> # do logging stuff > >>> pass > >>> > >>> @pytest.fixture > >>> def do_stuff(a, b): > >>> return DoStuff(a, b) > >>> > >>>best, > >>>holger > >>I still can't make it work: > >>=================================== FAILURES > >>=================================== > >>______________________________ TestAclass.test_1 > >>_______________________________ > >> > >>self = > >>request = > > >> > >> def test_1(self,request): > >>> ds=do_stuff(a,b) > >>E NameError: global name 'do_stuff' is not defined > >The "NameError" means that there is no reference to "do_stuff" in the test module. You need to list "do_stuff" in the function parameters, for example: > > > > def test_1(self, request, do_stuff): > > # here you can use "do_stuff" because it was passed in from > > # pytest by calling the "do_stuff" fixture function in > > # conftest.py and passing its result to test_1. > > > >holger > Go it I think. :-) > Where does the output go though? > > class TestAclass(): > def test_1(self,request,do_stuff): > print 'inside {0}-{1} > step'.format(self.__class__.__name__,request.function.__name__) > print 'a={0}, b={1}'.format(do_stuff.a,do_stuff.b) > do_stuff.log("we are here") > pass From dhunt at mozilla.com Wed Oct 26 15:45:02 2016 From: dhunt at mozilla.com (Dave Hunt) Date: Wed, 26 Oct 2016 20:45:02 +0100 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: References: Message-ID: <8E0E8155-E45B-4954-9A78-89F8A41C6B68@mozilla.com> Awesome shirt, thanks everyone! Dave Hunt > On 24 Oct 2016, at 19:29, Stefan Farmbauer wrote: > > Mine arrived too. Thanks a lot. It's really cool > > > Bruno Oliveira schrieb am Mo., 24. Okt. 2016 19:18: >> Pics or didn't happen! :) >> >> Still waiting for mine. ^^ >> >> On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: >> Hey, >> >> the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) >> >> Omar >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1.JPG Type: image/jpeg Size: 963304 bytes Desc: not available URL: From fp at gocept.com Thu Oct 27 03:29:55 2016 From: fp at gocept.com (Florian Pilz) Date: Thu, 27 Oct 2016 09:29:55 +0200 Subject: [pytest-dev] Moving pytest-rerunfailures to pytest-dev In-Reply-To: References: <40229627-C690-41D0-9734-A17EC6B40E3E@gocept.com> <20160202144555.GF542@tonks> <20160203071557.GK542@tonks> Message-ID: <51DEA29D-D95D-4F6B-A9D8-609AADD23A4C@gocept.com> Hi there! I?m moving forward and therefore want to transfer the maintenance of pytest-rerunfailures to Steffen Allner (you have probably met him at the pytest sprint this year, he is also working at gocept). Therefore could you please: * Add Steffen Allner (sallner at GitHub) to the pytest-dev team and the pytest-rerunfailures-admin group. * Add Michael Howitz (icemac at GitHub) to the pytest-dev team and the pytest-rerunfailures-developers group. Thanks a lot! > Am 03.02.2016 um 16:03 schrieb Bruno Oliveira : > > On Wed, Feb 3, 2016 at 5:15 AM Florian Bruhin > wrote: > - Every project has a pytest-xyz-admin team, with its projects admins > in it, having admin permissions on the repo. > > This was already present, I now also added it as a repo admin team, > so you should have full permissions to the repo again. > > - Every project has a pytest-xyz-developers team, having write (but > not admin) permission to the repo. I added the team and permissions, > and it's currently empty. If you want to add any people there, I > think we'll need to add them to the organization, and then you can > add them to the team. > > - The 'Contributors' group has write access to every project, and > every project admin is in it. I added it to pytest-rerunfailures, > and added you to the group. > > Bruno, does this sound correct to you? I think it was you who came up > with that scheme, right? > > That sounds reasonable, but IIRC who came up with this scheme was Bubenkov. > > Would be nice to have it documented > somewhere, but I don't really know where. Maybe in CONTRIBUTING. > > Sure, sounds like a good place for this information. Posted a note to #1282 to add it to that doc. > > (We have at least 3 Florians and 1 Floris in the team now... Phew :D) > > Heh! :D > > Bruno. > > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ ????????? Florian Pilz ? fp at gocept.com ? Software Developer gocept gmbh & co. kg ? Forsterstra?e 29 ? 06112 Halle (Saale) ? Germany http://gocept.com ? Tel +49 345 1229889-0 Individuelle Softwareentwicklung mit Python -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nicoddemus at gmail.com Thu Oct 27 05:16:46 2016 From: nicoddemus at gmail.com (Bruno Oliveira) Date: Thu, 27 Oct 2016 09:16:46 +0000 Subject: [pytest-dev] Moving pytest-rerunfailures to pytest-dev In-Reply-To: <51DEA29D-D95D-4F6B-A9D8-609AADD23A4C@gocept.com> References: <40229627-C690-41D0-9734-A17EC6B40E3E@gocept.com> <20160202144555.GF542@tonks> <20160203071557.GK542@tonks> <51DEA29D-D95D-4F6B-A9D8-609AADD23A4C@gocept.com> Message-ID: Florian, I did the request invitations. Once Steffen accepts it, I will also make him "Team Maintainer". Thanks and good luck! Cheers On Thu, Oct 27, 2016 at 5:28 AM Florian Pilz wrote: > Hi there! I?m moving forward and therefore want to transfer the > maintenance of pytest-rerunfailures to Steffen Allner (you have probably > met him at the pytest sprint this year, he is also working at gocept). > > Therefore could you please: > * Add Steffen Allner (sallner at GitHub) to the pytest-dev team and the > pytest-rerunfailures-admin group. > * Add Michael Howitz (icemac at GitHub) to the pytest-dev team and the > pytest-rerunfailures-developers group. > > Thanks a lot! > > Am 03.02.2016 um 16:03 schrieb Bruno Oliveira : > > On Wed, Feb 3, 2016 at 5:15 AM Florian Bruhin wrote: > > - Every project has a pytest-xyz-admin team, with its projects admins > in it, having admin permissions on the repo. > > This was already present, I now also added it as a repo admin team, > so you should have full permissions to the repo again. > > - Every project has a pytest-xyz-developers team, having write (but > not admin) permission to the repo. I added the team and permissions, > and it's currently empty. If you want to add any people there, I > think we'll need to add them to the organization, and then you can > add them to the team. > > - The 'Contributors' group has write access to every project, and > every project admin is in it. I added it to pytest-rerunfailures, > and added you to the group. > > Bruno, does this sound correct to you? I think it was you who came up > with that scheme, right? > > > That sounds reasonable, but IIRC who came up with this scheme was > Bubenkov. > > > Would be nice to have it documented > somewhere, but I don't really know where. Maybe in CONTRIBUTING. > > > Sure, sounds like a good place for this information. Posted a note to > #1282 to add it to that doc. > > (We have at least 3 Florians and 1 Floris in the team now... Phew :D) > > > Heh! :D > > Bruno. > > > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > > > ????????? > Florian Pilz ? fp at gocept.com ? Software Developer > gocept gmbh & co. kg ? Forsterstra?e 29 ? 06112 Halle (Saale) ? Germany > http://gocept.com ? Tel +49 345 1229889-0 <+49%20345%2012298890> > Individuelle Softwareentwicklung mit Python > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpfannsc at redhat.com Thu Oct 27 06:09:07 2016 From: rpfannsc at redhat.com (Ronny Pfannschmidt) Date: Thu, 27 Oct 2016 12:09:07 +0200 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: <8E0E8155-E45B-4954-9A78-89F8A41C6B68@mozilla.com> References: <8E0E8155-E45B-4954-9A78-89F8A41C6B68@mozilla.com> Message-ID: mine arrived as well :) 2016-10-26 21:45 GMT+02:00 Dave Hunt : > Awesome shirt, thanks everyone! > > [image: image1.JPG] > > Dave Hunt > > On 24 Oct 2016, at 19:29, Stefan Farmbauer wrote: > > Mine arrived too. Thanks a lot. It's really cool > > Bruno Oliveira schrieb am Mo., 24. Okt. 2016 19:18: > >> Pics or didn't happen! :) >> >> Still waiting for mine. ^^ >> >> On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: >> >> Hey, >> >> the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) >> >> Omar >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1.JPG Type: image/jpeg Size: 963304 bytes Desc: not available URL: From aninhacostaribeiro at gmail.com Thu Oct 27 08:21:16 2016 From: aninhacostaribeiro at gmail.com (Ana Ribeiro) Date: Thu, 27 Oct 2016 09:21:16 -0300 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: References: <8E0E8155-E45B-4954-9A78-89F8A41C6B68@mozilla.com> Message-ID: Seems it gets longer to get in Brazil :'( Still waiting for mine too. 2016-10-27 7:09 GMT-03:00 Ronny Pfannschmidt : > mine arrived as well :) > > 2016-10-26 21:45 GMT+02:00 Dave Hunt : > >> Awesome shirt, thanks everyone! >> >> [image: image1.JPG] >> >> Dave Hunt >> >> On 24 Oct 2016, at 19:29, Stefan Farmbauer wrote: >> >> Mine arrived too. Thanks a lot. It's really cool >> >> Bruno Oliveira schrieb am Mo., 24. Okt. 2016 >> 19:18: >> >>> Pics or didn't happen! :) >>> >>> Still waiting for mine. ^^ >>> >>> On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: >>> >>> Hey, >>> >>> the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) >>> >>> Omar >>> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev at python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >>> _______________________________________________ >>> pytest-dev mailing list >>> pytest-dev at python.org >>> https://mail.python.org/mailman/listinfo/pytest-dev >>> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev at python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> >> > > > -- > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1.JPG Type: image/jpeg Size: 963304 bytes Desc: not available URL: From oliver at bestwalter.de Thu Oct 27 14:56:56 2016 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Thu, 27 Oct 2016 18:56:56 +0000 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: References: <8E0E8155-E45B-4954-9A78-89F8A41C6B68@mozilla.com> Message-ID: Hi all, mine arrived today. Thanks a lot! Cheers Oliver On Thu, 27 Oct 2016 at 14:22 Ana Ribeiro wrote: > Seems it gets longer to get in Brazil :'( Still waiting for mine too. > > 2016-10-27 7:09 GMT-03:00 Ronny Pfannschmidt : > > mine arrived as well :) > > 2016-10-26 21:45 GMT+02:00 Dave Hunt : > > Awesome shirt, thanks everyone! > > [image: image1.JPG] > > Dave Hunt > > On 24 Oct 2016, at 19:29, Stefan Farmbauer wrote: > > Mine arrived too. Thanks a lot. It's really cool > > Bruno Oliveira schrieb am Mo., 24. Okt. 2016 19:18: > > Pics or didn't happen! :) > > Still waiting for mine. ^^ > > On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: > > Hey, > > the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) > > Omar > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > -- > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1.JPG Type: image/jpeg Size: 963304 bytes Desc: not available URL: From oliver at bestwalter.de Thu Oct 27 15:08:37 2016 From: oliver at bestwalter.de (Oliver Bestwalter) Date: Thu, 27 Oct 2016 19:08:37 +0000 Subject: [pytest-dev] t-shirts and stickers now out, thanks Florian! In-Reply-To: <20161025134308.aqo2qbkndd2dhhmr@tonks> References: <20161025110411.GH4522@merlinux.eu> <20161025134308.aqo2qbkndd2dhhmr@tonks> Message-ID: Hi Florian, I really appreciate, that you opted for the harder but better quality route. The quality is really good - this comes from an enthusiastic T-Shirt wearer since the early 1980s - so thanks for going through all the trouble :) Cheers Oliver On Tue, 25 Oct 2016 at 15:43 Florian Bruhin wrote: > * Ronny Pfannschmidt [2016-10-25 > 15:15:06 +0200]: > > Given the funding volumes and used amounts, > > i wonder if, with the funds that are left, we could have the next > > sprints sponsored mostly by cooperates > > next time, > > > > I propose that those of us working in a company that could/should > > participate kick off the > > "paperwork mill" to see if that idea is viable. > > FWIW more than half of the money was already coming from companies. > > Florian > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvas.it at gmail.com Fri Oct 28 08:54:21 2016 From: kvas.it at gmail.com (Vasily Kuznetsov) Date: Fri, 28 Oct 2016 12:54:21 +0000 Subject: [pytest-dev] T-Shirt has arrived! In-Reply-To: References: <8E0E8155-E45B-4954-9A78-89F8A41C6B68@mozilla.com> Message-ID: I got mine too and it's awesome! Thanks Florian for doing all the grunt work of getting this printed. On Thu, Oct 27, 2016 at 9:28 PM Oliver Bestwalter wrote: > Hi all, > > mine arrived today. Thanks a lot! > > Cheers > Oliver > > On Thu, 27 Oct 2016 at 14:22 Ana Ribeiro > wrote: > > Seems it gets longer to get in Brazil :'( Still waiting for mine too. > > 2016-10-27 7:09 GMT-03:00 Ronny Pfannschmidt : > > mine arrived as well :) > > 2016-10-26 21:45 GMT+02:00 Dave Hunt : > > Awesome shirt, thanks everyone! > > [image: image1.JPG] > > Dave Hunt > > On 24 Oct 2016, at 19:29, Stefan Farmbauer wrote: > > Mine arrived too. Thanks a lot. It's really cool > > Bruno Oliveira schrieb am Mo., 24. Okt. 2016 19:18: > > Pics or didn't happen! :) > > Still waiting for mine. ^^ > > On Mon, Oct 24, 2016 at 3:04 PM Omar Kohl wrote: > > Hey, > > the 2016 Sprint T-Shirt arrived today! Thanks a lot, very cool :-) > > Omar > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > -- > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdent at anticdent.org Fri Oct 28 09:04:08 2016 From: cdent at anticdent.org (Chris Dent) Date: Fri, 28 Oct 2016 15:04:08 +0200 (CEST) Subject: [pytest-dev] process for replacing yield tests with modern style In-Reply-To: <20161022172711.GA4522@merlinux.eu> References: <20161022172711.GA4522@merlinux.eu> Message-ID: On Sat, 22 Oct 2016, holger krekel wrote: > maybe there is a solution ... Thanks I think this has potentially given me enough to at least fix the old simple version found in: > So let's now get to your original example at > https://github.com/tiddlyweb/tiddlyweb/blob/master/test/http_runner.py and that might be enough to increase my understanding so that I can deal with the considerably more complex form used in gabbi. I'll come back to this thread with: * a link to the change in tiddlyweb when it is working * questions when I get stuck with gabbi > def pytest_generate_tests(metafunc): > if metafunc.function == test_generic: > l = [] > for test_data in tests: > test = dict(EMPTY_TEST) > test.update(test_data) > l.append(test) > > metafunc.parametrize("test", argvalues=l, ids=ids) > > def test_generic(test): > ... > > haven't tested this -- does it work for you? I had to make some minor modifications and get the methods in the right files, but I was able to get something roughly working that once cleaned up will be okay. Thanks. -- Chris Dent ????( ? _ ??) https://anticdent.org/ freenode: cdent tw: @anticdent From cdent at anticdent.org Mon Oct 31 11:30:36 2016 From: cdent at anticdent.org (Chris Dent) Date: Mon, 31 Oct 2016 15:30:36 +0000 (GMT) Subject: [pytest-dev] process for replacing yield tests with modern style In-Reply-To: References: <20161022172711.GA4522@merlinux.eu> Message-ID: On Fri, 28 Oct 2016, Chris Dent wrote: > On Sat, 22 Oct 2016, holger krekel wrote: >> So let's now get to your original example at >> https://github.com/tiddlyweb/tiddlyweb/blob/master/test/http_runner.py > > and that might be enough to increase my understanding so that I can > deal with the considerably more complex form used in gabbi. I'll > come back to this thread with: > > * a link to the change in tiddlyweb when it is working https://github.com/tiddlyweb/tiddlyweb/pull/106 This seems to be working reasonably well so barring any comments from here or elsewhere, I'll just merge that and \o/. > * questions when I get stuck with gabbi I've started a branch where I try to transfoer what I learned on the above to the gabbi work, and while I have a proof of concept working, it isn't very clean: https://github.com/cdent/gabbi/commit/6dd40c42907a069b686f5348eb95134a0c3b93be The commit message explains the issues. The gist is that I want to make things as easy as possible for the test author (the user of gabbi) and expose the details of pytest as little as possible. -- Chris Dent ????( ? _ ??) https://anticdent.org/ freenode: cdent tw: @anticdent