From ws at gocept.com Fri Apr 4 11:21:58 2014 From: ws at gocept.com (Wolfgang Schnerring) Date: Fri, 4 Apr 2014 11:21:58 +0200 Subject: [pytest-dev] Access fixtures from unittest.TestCase Message-ID: <20140404112158.7d8b35a2@widnar> Hello, is there a way to access a fixture object from inside a unitest.TestCase test function? As far as I understand, the way to combine fixtures and TestCase is like this: import pytest, unittest @pytest.mark.usefixtures('tmpdir') class MyTest(unittest.TestCase): def test_something(self): # XXX how can I get to ``tmpdir`` here? But there seems to be no way to get to the fixture object, which is rather constraining. Or am I missing something? Thanks for your help, Wolfgang From kkurian at gmail.com Sun Apr 6 08:15:23 2014 From: kkurian at gmail.com (Kerry Kurian) Date: Sun, 6 Apr 2014 00:15:23 -0600 Subject: [pytest-dev] pytest-cov +gevent reporting incorrect results Message-ID: Are there any updates on this? From holger at merlinux.eu Mon Apr 7 12:24:27 2014 From: holger at merlinux.eu (holger krekel) Date: Mon, 7 Apr 2014 10:24:27 +0000 Subject: [pytest-dev] Access fixtures from unittest.TestCase In-Reply-To: <20140404112158.7d8b35a2@widnar> References: <20140404112158.7d8b35a2@widnar> Message-ID: <20140407102427.GH7198@merlinux.eu> Hi Wolfgang, On Fri, Apr 04, 2014 at 11:21 +0200, Wolfgang Schnerring wrote: > Hello, > > is there a way to access a fixture object from inside a unitest.TestCase test > function? As far as I understand, the way to combine fixtures and TestCase is > like this: > > import pytest, unittest > > @pytest.mark.usefixtures('tmpdir') > class MyTest(unittest.TestCase): > > def test_something(self): > # XXX how can I get to ``tmpdir`` here? > > But there seems to be no way to get to the fixture object, which is rather > constraining. Or am I missing something? Right, any "usefixture" needs to either have a global side effect or stick some object to "self". One easier way to get a tempdir is this: class MyTest(unittest.TestCase): @pytest.fixture(autouse=True) def set_tmpdir(self, tmpdir): self.tmpdir = tmpdir def test_something(self): # access self.tmpdir HTH, holger > Thanks for your help, > Wolfgang > > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From anton7811 at gmail.com Mon Apr 7 12:43:48 2014 From: anton7811 at gmail.com (Anton P) Date: Mon, 7 Apr 2014 13:43:48 +0300 Subject: [pytest-dev] Unexpected fixture behaviour. Message-ID: Hi All, Recently we switched our test environment from funcargs to fixtures and found unexpected and unwanted behaviour: In case fixture finalizer failed next time fixture won't be set up. Here I have 2 fixtures: env_main - module level env - functional level (env_main child) In pytest output you can see message that env was created before test_1 ("INIT_ENV" message). Then it failed on finalizer after "DESTROY ENV" message. PROBLEM: test_2 that requires env fixture is launched but without env fixture. I expect that function level fixture will be recreated for the next test function, or at least all other test functions will fail without launching. I don't see any reason why they have to be launched in case fixture cannot be set up. But it's better to try to recreate fixture for next iteration (e.g. next function if scope is function) I see there was an issue #287 which is marked as resolved. But as for me it could be reopened. I see that in case we add more test cases, then the fixture will be created for the 3d test function but again skipped for the 4th test function. Is it possible to change current default behaviour? Thank you in advance! Anton P.S. Please find code files attached. Here is execution log: $ py.test -v -s test_params.py ============================ test session starts ============================ platform linux2 -- Python 2.7.3 -- py-1.4.20 -- pytest-2.5.2 -- /usr/bin/python plugins: cov collected 2 items test_params.py:4: TestClass.test_1 Create ENV_MAIN INIT ENV PASSEDDESTROY ENV test_params.py:4: TestClass.test_1 ERROR test_params.py:7: TestClass.test_2 PASSEDDestroy ENV_MAIN ================================== ERRORS =================================== ___________________ ERROR at teardown of TestClass.test_1 ___________________ self = def teardown(self): print "DESTROY ENV" > assert 0 E assert 0 conftest.py:30: AssertionError ===================== 2 passed, 1 error in 0.01 seconds ===================== -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: conftest.py Type: text/x-python Size: 898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test_params.py Type: text/x-python Size: 115 bytes Desc: not available URL: From holger at merlinux.eu Mon Apr 7 12:51:45 2014 From: holger at merlinux.eu (holger krekel) Date: Mon, 7 Apr 2014 10:51:45 +0000 Subject: [pytest-dev] Unexpected fixture behaviour. In-Reply-To: References: Message-ID: <20140407105145.GM7198@merlinux.eu> Hi Anton, just to understand better -- you also switched pytest versions or not? A mere change from "pytest_funcarg__" syntax to "@pytest.fixture" syntax should not have such an effect. There also is issue498 which might be related, btw: https://bitbucket.org/hpk42/pytest/issue/498/function-scope-fixture-with-failing Could you file an issue against the tracker and/or add to 498? best and thanks, holger On Mon, Apr 07, 2014 at 13:43 +0300, Anton P wrote: > Hi All, > > Recently we switched our test environment from funcargs to fixtures and > found unexpected and unwanted behaviour: In case fixture finalizer failed > next time fixture won't be set up. > > Here I have 2 fixtures: > env_main - module level > env - functional level (env_main child) > > In pytest output you can see message that env was created before test_1 > ("INIT_ENV" message). Then it failed on finalizer after "DESTROY ENV" > message. > PROBLEM: test_2 that requires env fixture is launched but without env > fixture. > I expect that function level fixture will be recreated for the next test > function, or at least all other test functions will fail without launching. > I don't see any reason why they have to be launched in case fixture cannot > be set up. But it's better to try to recreate fixture for next iteration > (e.g. next function if scope is function) > > I see there was an issue #287 which is marked as resolved. But as for me it > could be reopened. > > I see that in case we add more test cases, then the fixture will be created > for the 3d test function but again skipped for the 4th test function. > > Is it possible to change current default behaviour? > > Thank you in advance! > Anton > > P.S. > Please find code files attached. > > Here is execution log: > > $ py.test -v -s test_params.py > ============================ test session starts > ============================ > platform linux2 -- Python 2.7.3 -- py-1.4.20 -- pytest-2.5.2 -- > /usr/bin/python > plugins: cov > collected 2 items > > test_params.py:4: TestClass.test_1 Create ENV_MAIN > INIT ENV > PASSEDDESTROY ENV > > test_params.py:4: TestClass.test_1 ERROR > test_params.py:7: TestClass.test_2 PASSEDDestroy ENV_MAIN > > > ================================== ERRORS > =================================== > ___________________ ERROR at teardown of TestClass.test_1 > ___________________ > > self = > > def teardown(self): > print "DESTROY ENV" > > assert 0 > E assert 0 > > conftest.py:30: AssertionError > ===================== 2 passed, 1 error in 0.01 seconds > ===================== > import pytest > import sys > > class Env(): > def __init__(self): > self.env = 1 > > def create(self): > print "Create ENV_MAIN" > > return self.env > > def destroy(self): > print "Destroy ENV_MAIN" > > > class EnvTest(): > > def __init__(self, request, env): > self.request = request > self.env = env > self.request.node.call_status = False > > def setup(self): > print "INIT ENV" > self.request.node.call_status = True > > def teardown(self): > print "DESTROY ENV" > assert 0 > > > > @pytest.fixture(scope="module") > def env_main(request): > env_wrapper = Env() > > request.addfinalizer(env_wrapper.destroy) > request.config.env = env_wrapper.create() > > return env_wrapper > > @pytest.fixture > def env(request, env_main): > env = EnvTest(request, env_main) > request.addfinalizer(env.teardown) > env.setup() > > return env_main > import pytest > > class TestClass(): > def test_1(self, env): > pass > > def test_2(self, env): > pass > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From anton7811 at gmail.com Mon Apr 7 12:55:50 2014 From: anton7811 at gmail.com (Anton P) Date: Mon, 7 Apr 2014 13:55:50 +0300 Subject: [pytest-dev] Unexpected fixture behaviour. In-Reply-To: <20140407105145.GM7198@merlinux.eu> References: <20140407105145.GM7198@merlinux.eu> Message-ID: Hi Holger, Thank you for your response! No, we haven't switched py.test versions. We just move all setup/teardown procedures from pytest hooks to fixtures. I'll update issue #498. Thank you! Anton On Mon, Apr 7, 2014 at 1:51 PM, holger krekel wrote: > Hi Anton, > > just to understand better -- you also switched pytest versions or not? > A mere change from "pytest_funcarg__" syntax to "@pytest.fixture" > syntax should not have such an effect. > > There also is issue498 which might be related, btw: > > https://bitbucket.org/hpk42/pytest/issue/498/function-scope-fixture-with-failing > > Could you file an issue against the tracker and/or add to 498? > > best and thanks, > > holger > > On Mon, Apr 07, 2014 at 13:43 +0300, Anton P wrote: > > Hi All, > > > > Recently we switched our test environment from funcargs to fixtures and > > found unexpected and unwanted behaviour: In case fixture finalizer failed > > next time fixture won't be set up. > > > > Here I have 2 fixtures: > > env_main - module level > > env - functional level (env_main child) > > > > In pytest output you can see message that env was created before test_1 > > ("INIT_ENV" message). Then it failed on finalizer after "DESTROY ENV" > > message. > > PROBLEM: test_2 that requires env fixture is launched but without env > > fixture. > > I expect that function level fixture will be recreated for the next test > > function, or at least all other test functions will fail without > launching. > > I don't see any reason why they have to be launched in case fixture > cannot > > be set up. But it's better to try to recreate fixture for next iteration > > (e.g. next function if scope is function) > > > > I see there was an issue #287 which is marked as resolved. But as for me > it > > could be reopened. > > > > I see that in case we add more test cases, then the fixture will be > created > > for the 3d test function but again skipped for the 4th test function. > > > > Is it possible to change current default behaviour? > > > > Thank you in advance! > > Anton > > > > P.S. > > Please find code files attached. > > > > Here is execution log: > > > > $ py.test -v -s test_params.py > > ============================ test session starts > > ============================ > > platform linux2 -- Python 2.7.3 -- py-1.4.20 -- pytest-2.5.2 -- > > /usr/bin/python > > plugins: cov > > collected 2 items > > > > test_params.py:4: TestClass.test_1 Create ENV_MAIN > > INIT ENV > > PASSEDDESTROY ENV > > > > test_params.py:4: TestClass.test_1 ERROR > > test_params.py:7: TestClass.test_2 PASSEDDestroy ENV_MAIN > > > > > > ================================== ERRORS > > =================================== > > ___________________ ERROR at teardown of TestClass.test_1 > > ___________________ > > > > self = > > > > def teardown(self): > > print "DESTROY ENV" > > > assert 0 > > E assert 0 > > > > conftest.py:30: AssertionError > > ===================== 2 passed, 1 error in 0.01 seconds > > ===================== > > > import pytest > > import sys > > > > class Env(): > > def __init__(self): > > self.env = 1 > > > > def create(self): > > print "Create ENV_MAIN" > > > > return self.env > > > > def destroy(self): > > print "Destroy ENV_MAIN" > > > > > > class EnvTest(): > > > > def __init__(self, request, env): > > self.request = request > > self.env = env > > self.request.node.call_status = False > > > > def setup(self): > > print "INIT ENV" > > self.request.node.call_status = True > > > > def teardown(self): > > print "DESTROY ENV" > > assert 0 > > > > > > > > @pytest.fixture(scope="module") > > def env_main(request): > > env_wrapper = Env() > > > > request.addfinalizer(env_wrapper.destroy) > > request.config.env = env_wrapper.create() > > > > return env_wrapper > > > > @pytest.fixture > > def env(request, env_main): > > env = EnvTest(request, env_main) > > request.addfinalizer(env.teardown) > > env.setup() > > > > return env_main > > > import pytest > > > > class TestClass(): > > def test_1(self, env): > > pass > > > > def test_2(self, env): > > pass > > > _______________________________________________ > > 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 Mon Apr 7 13:00:08 2014 From: holger at merlinux.eu (holger krekel) Date: Mon, 7 Apr 2014 11:00:08 +0000 Subject: [pytest-dev] Unexpected fixture behaviour. In-Reply-To: References: <20140407105145.GM7198@merlinux.eu> Message-ID: <20140407110008.GN7198@merlinux.eu> Hi again, On Mon, Apr 07, 2014 at 13:55 +0300, Anton P wrote: > Hi Holger, > > Thank you for your response! > > No, we haven't switched py.test versions. We just move all setup/teardown > procedures from pytest hooks to fixtures. > > I'll update issue #498. great, thanks. I think that in case of a failing finalizer a fixture might be marked as "broken" or so, and no attempt at re-creating it be made. Subsequent tests would not run (not sure how that gets reported exactly, though). Reporting a teardown error and then trying to recreate it might work in some cases but might also lead to even stranger errors because the fixture might still be half-setup due to the failed finalizer. best, holger > Thank you! > Anton > > > On Mon, Apr 7, 2014 at 1:51 PM, holger krekel wrote: > > > Hi Anton, > > > > just to understand better -- you also switched pytest versions or not? > > A mere change from "pytest_funcarg__" syntax to "@pytest.fixture" > > syntax should not have such an effect. > > > > There also is issue498 which might be related, btw: > > > > https://bitbucket.org/hpk42/pytest/issue/498/function-scope-fixture-with-failing > > > > Could you file an issue against the tracker and/or add to 498? > > > > best and thanks, > > > > holger > > > > On Mon, Apr 07, 2014 at 13:43 +0300, Anton P wrote: > > > Hi All, > > > > > > Recently we switched our test environment from funcargs to fixtures and > > > found unexpected and unwanted behaviour: In case fixture finalizer failed > > > next time fixture won't be set up. > > > > > > Here I have 2 fixtures: > > > env_main - module level > > > env - functional level (env_main child) > > > > > > In pytest output you can see message that env was created before test_1 > > > ("INIT_ENV" message). Then it failed on finalizer after "DESTROY ENV" > > > message. > > > PROBLEM: test_2 that requires env fixture is launched but without env > > > fixture. > > > I expect that function level fixture will be recreated for the next test > > > function, or at least all other test functions will fail without > > launching. > > > I don't see any reason why they have to be launched in case fixture > > cannot > > > be set up. But it's better to try to recreate fixture for next iteration > > > (e.g. next function if scope is function) > > > > > > I see there was an issue #287 which is marked as resolved. But as for me > > it > > > could be reopened. > > > > > > I see that in case we add more test cases, then the fixture will be > > created > > > for the 3d test function but again skipped for the 4th test function. > > > > > > Is it possible to change current default behaviour? > > > > > > Thank you in advance! > > > Anton > > > > > > P.S. > > > Please find code files attached. > > > > > > Here is execution log: > > > > > > $ py.test -v -s test_params.py > > > ============================ test session starts > > > ============================ > > > platform linux2 -- Python 2.7.3 -- py-1.4.20 -- pytest-2.5.2 -- > > > /usr/bin/python > > > plugins: cov > > > collected 2 items > > > > > > test_params.py:4: TestClass.test_1 Create ENV_MAIN > > > INIT ENV > > > PASSEDDESTROY ENV > > > > > > test_params.py:4: TestClass.test_1 ERROR > > > test_params.py:7: TestClass.test_2 PASSEDDestroy ENV_MAIN > > > > > > > > > ================================== ERRORS > > > =================================== > > > ___________________ ERROR at teardown of TestClass.test_1 > > > ___________________ > > > > > > self = > > > > > > def teardown(self): > > > print "DESTROY ENV" > > > > assert 0 > > > E assert 0 > > > > > > conftest.py:30: AssertionError > > > ===================== 2 passed, 1 error in 0.01 seconds > > > ===================== > > > > > import pytest > > > import sys > > > > > > class Env(): > > > def __init__(self): > > > self.env = 1 > > > > > > def create(self): > > > print "Create ENV_MAIN" > > > > > > return self.env > > > > > > def destroy(self): > > > print "Destroy ENV_MAIN" > > > > > > > > > class EnvTest(): > > > > > > def __init__(self, request, env): > > > self.request = request > > > self.env = env > > > self.request.node.call_status = False > > > > > > def setup(self): > > > print "INIT ENV" > > > self.request.node.call_status = True > > > > > > def teardown(self): > > > print "DESTROY ENV" > > > assert 0 > > > > > > > > > > > > @pytest.fixture(scope="module") > > > def env_main(request): > > > env_wrapper = Env() > > > > > > request.addfinalizer(env_wrapper.destroy) > > > request.config.env = env_wrapper.create() > > > > > > return env_wrapper > > > > > > @pytest.fixture > > > def env(request, env_main): > > > env = EnvTest(request, env_main) > > > request.addfinalizer(env.teardown) > > > env.setup() > > > > > > return env_main > > > > > import pytest > > > > > > class TestClass(): > > > def test_1(self, env): > > > pass > > > > > > def test_2(self, env): > > > pass > > > > > _______________________________________________ > > > Pytest-dev mailing list > > > Pytest-dev at python.org > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > From ws at gocept.com Mon Apr 7 13:18:31 2014 From: ws at gocept.com (Wolfgang Schnerring) Date: Mon, 7 Apr 2014 13:18:31 +0200 Subject: [pytest-dev] Access fixtures from unittest.TestCase References: <20140404112158.7d8b35a2@widnar> <20140407102427.GH7198@merlinux.eu> Message-ID: <20140407131831.15b49fac@widnar> Hello Holger, * holger krekel [2014-04-07 10:24]: > On Fri, Apr 04, 2014 at 11:21 +0200, Wolfgang Schnerring wrote: > > is there a way to access a fixture object from inside a unitest.TestCase > > test function? > Right, any "usefixture" needs to either have a global side effect > or stick some object to "self". > @pytest.fixture(autouse=True) > def set_tmpdir(self, tmpdir): > self.tmpdir = tmpdir Thanks for the hint! Using a method of the TestCase as a wrapper fixture around the actual fixture is clever, but also a little unwieldy... would there be an easy way to introduce an API to make that easier? Wolfgang From holger at merlinux.eu Mon Apr 7 13:27:40 2014 From: holger at merlinux.eu (holger krekel) Date: Mon, 7 Apr 2014 11:27:40 +0000 Subject: [pytest-dev] Access fixtures from unittest.TestCase In-Reply-To: <20140407131831.15b49fac@widnar> References: <20140404112158.7d8b35a2@widnar> <20140407102427.GH7198@merlinux.eu> <20140407131831.15b49fac@widnar> Message-ID: <20140407112740.GP7198@merlinux.eu> Hi Wolfgang, On Mon, Apr 07, 2014 at 13:18 +0200, Wolfgang Schnerring wrote: > Hello Holger, > > * holger krekel [2014-04-07 10:24]: > > On Fri, Apr 04, 2014 at 11:21 +0200, Wolfgang Schnerring wrote: > > > is there a way to access a fixture object from inside a unitest.TestCase > > > test function? > > Right, any "usefixture" needs to either have a global side effect > > or stick some object to "self". > > @pytest.fixture(autouse=True) > > def set_tmpdir(self, tmpdir): > > self.tmpdir = tmpdir > > Thanks for the hint! Using a method of the TestCase as a wrapper > fixture around the actual fixture is clever, but also a little > unwieldy... would there be an easy way to introduce an API to make > that easier? Thing is that trying to bring pytest fixtures to unittest.TestCase's methods directly is very hard, especially given the many extensions/subclasses that people use. If unittest had a plugin system that would help. do you have to inherit unittest.TestCase, btw? If you don't, all problems go away :) best, holger > Wolfgang > > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From anton7811 at gmail.com Mon Apr 7 15:34:44 2014 From: anton7811 at gmail.com (Anton P) Date: Mon, 7 Apr 2014 16:34:44 +0300 Subject: [pytest-dev] Unexpected fixture behaviour. In-Reply-To: <20140407110008.GN7198@merlinux.eu> References: <20140407105145.GM7198@merlinux.eu> <20140407110008.GN7198@merlinux.eu> Message-ID: Hi Holger! I saw your commit and patched pytest2.5.2 with it. It works in my case. Thank you very much! Anton On Mon, Apr 7, 2014 at 2:00 PM, holger krekel wrote: > Hi again, > > On Mon, Apr 07, 2014 at 13:55 +0300, Anton P wrote: > > Hi Holger, > > > > Thank you for your response! > > > > No, we haven't switched py.test versions. We just move all setup/teardown > > procedures from pytest hooks to fixtures. > > > > I'll update issue #498. > > great, thanks. I think that in case of a failing finalizer a fixture > might be marked as "broken" or so, and no attempt at re-creating it > be made. Subsequent tests would not run (not sure how that gets reported > exactly, though). Reporting a teardown error and then trying to > recreate it might work in some cases but might also lead to even > stranger errors because the fixture might still be half-setup > due to the failed finalizer. > > best, > holger > > > > Thank you! > > Anton > > > > > > On Mon, Apr 7, 2014 at 1:51 PM, holger krekel > wrote: > > > > > Hi Anton, > > > > > > just to understand better -- you also switched pytest versions or not? > > > A mere change from "pytest_funcarg__" syntax to "@pytest.fixture" > > > syntax should not have such an effect. > > > > > > There also is issue498 which might be related, btw: > > > > > > > https://bitbucket.org/hpk42/pytest/issue/498/function-scope-fixture-with-failing > > > > > > Could you file an issue against the tracker and/or add to 498? > > > > > > best and thanks, > > > > > > holger > > > > > > On Mon, Apr 07, 2014 at 13:43 +0300, Anton P wrote: > > > > Hi All, > > > > > > > > Recently we switched our test environment from funcargs to fixtures > and > > > > found unexpected and unwanted behaviour: In case fixture finalizer > failed > > > > next time fixture won't be set up. > > > > > > > > Here I have 2 fixtures: > > > > env_main - module level > > > > env - functional level (env_main child) > > > > > > > > In pytest output you can see message that env was created before > test_1 > > > > ("INIT_ENV" message). Then it failed on finalizer after "DESTROY ENV" > > > > message. > > > > PROBLEM: test_2 that requires env fixture is launched but without env > > > > fixture. > > > > I expect that function level fixture will be recreated for the next > test > > > > function, or at least all other test functions will fail without > > > launching. > > > > I don't see any reason why they have to be launched in case fixture > > > cannot > > > > be set up. But it's better to try to recreate fixture for next > iteration > > > > (e.g. next function if scope is function) > > > > > > > > I see there was an issue #287 which is marked as resolved. But as > for me > > > it > > > > could be reopened. > > > > > > > > I see that in case we add more test cases, then the fixture will be > > > created > > > > for the 3d test function but again skipped for the 4th test function. > > > > > > > > Is it possible to change current default behaviour? > > > > > > > > Thank you in advance! > > > > Anton > > > > > > > > P.S. > > > > Please find code files attached. > > > > > > > > Here is execution log: > > > > > > > > $ py.test -v -s test_params.py > > > > ============================ test session starts > > > > ============================ > > > > platform linux2 -- Python 2.7.3 -- py-1.4.20 -- pytest-2.5.2 -- > > > > /usr/bin/python > > > > plugins: cov > > > > collected 2 items > > > > > > > > test_params.py:4: TestClass.test_1 Create ENV_MAIN > > > > INIT ENV > > > > PASSEDDESTROY ENV > > > > > > > > test_params.py:4: TestClass.test_1 ERROR > > > > test_params.py:7: TestClass.test_2 PASSEDDestroy ENV_MAIN > > > > > > > > > > > > ================================== ERRORS > > > > =================================== > > > > ___________________ ERROR at teardown of TestClass.test_1 > > > > ___________________ > > > > > > > > self = > > > > > > > > def teardown(self): > > > > print "DESTROY ENV" > > > > > assert 0 > > > > E assert 0 > > > > > > > > conftest.py:30: AssertionError > > > > ===================== 2 passed, 1 error in 0.01 seconds > > > > ===================== > > > > > > > import pytest > > > > import sys > > > > > > > > class Env(): > > > > def __init__(self): > > > > self.env = 1 > > > > > > > > def create(self): > > > > print "Create ENV_MAIN" > > > > > > > > return self.env > > > > > > > > def destroy(self): > > > > print "Destroy ENV_MAIN" > > > > > > > > > > > > class EnvTest(): > > > > > > > > def __init__(self, request, env): > > > > self.request = request > > > > self.env = env > > > > self.request.node.call_status = False > > > > > > > > def setup(self): > > > > print "INIT ENV" > > > > self.request.node.call_status = True > > > > > > > > def teardown(self): > > > > print "DESTROY ENV" > > > > assert 0 > > > > > > > > > > > > > > > > @pytest.fixture(scope="module") > > > > def env_main(request): > > > > env_wrapper = Env() > > > > > > > > request.addfinalizer(env_wrapper.destroy) > > > > request.config.env = env_wrapper.create() > > > > > > > > return env_wrapper > > > > > > > > @pytest.fixture > > > > def env(request, env_main): > > > > env = EnvTest(request, env_main) > > > > request.addfinalizer(env.teardown) > > > > env.setup() > > > > > > > > return env_main > > > > > > > import pytest > > > > > > > > class TestClass(): > > > > def test_1(self, env): > > > > pass > > > > > > > > def test_2(self, env): > > > > pass > > > > > > > _______________________________________________ > > > > 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 marc.schlaich at gmail.com Tue Apr 8 09:01:33 2014 From: marc.schlaich at gmail.com (Marc Schlaich) Date: Tue, 8 Apr 2014 09:01:33 +0200 Subject: [pytest-dev] Announcement: new maintainer for pytest-cov and cov-core Message-ID: Hey, as the original author of these packages is unresponsive for almost two years now, I requested maintainer status on PyPI ( http://sourceforge.net/p/pypi/support-requests/352/). If anyone is interested in (co-)maintaining any of these packages please get in touch. I'm happy to share or transfer responsibility if someone is more suitable than me. I'm considering moving the repositories to GitHub. What do you think about that? Additionally, I got maintainer status of nose-cov and nose2-cov (because they are from the same author) but I'm not interested in actively maintaining them. If someone is willing to take these over just let me know. Regards, Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ws at gocept.com Tue Apr 8 08:20:00 2014 From: ws at gocept.com (Wolfgang Schnerring) Date: Tue, 8 Apr 2014 08:20:00 +0200 Subject: [pytest-dev] Access fixtures from unittest.TestCase References: <20140404112158.7d8b35a2@widnar> <20140407102427.GH7198@merlinux.eu> <20140407131831.15b49fac@widnar> <20140407112740.GP7198@merlinux.eu> Message-ID: <20140408082000.65e456b5@widnar> Hello, > > Thanks for the hint! Using a method of the TestCase as a wrapper > > fixture around the actual fixture is clever, but also a little > > unwieldy... would there be an easy way to introduce an API to make > > that easier? > > Thing is that trying to bring pytest fixtures to unittest.TestCase's > methods directly is very hard, especially given the many > extensions/subclasses that people use. Yeah, I can see how that might be a rather annoying proposition. On the other hand... I'm not too familiar with the pytest internals (yet? ;), so this might be totally crazy, but would it be feasible to have an API like pytest.get_fixture('myfixturename') to retrieve the fixture object? Or is there no such kind of registry and they are all handled local to the test function? > do you have to inherit unittest.TestCase, btw? > If you don't, all problems go away :) Yes I do; my use case is migrating projects with large test suites (several thousand test functions across dozens of packages) from unittest/zope.testrunner to pytest. Thus, we need mechanisms that work gradually, since anything that requires us to change something /everywhere/ is a non-starter. We've already got fancy tooling[1] that converts zope.testrunner-style "layers"[2] to pytest fixtures, but as you noted above, some test infrastructure is hidden away in TestCase base classes. So, even if I start a new package that uses pytest/fixtures from the ground up (as I did last week ;), I still need to integrate with some older packages, and their TestCases. But I guess I can work with the workaround you gave (using a TestCase method as a fixture to wrap the actual fixture), while refactoring stuff piecemeal to provide test infrastructure in a testframework-independent way (you know, being testframework-indepent really isn't a use-case usually...) Thanks again, Wolfgang [1] https://pypi.python.org/pypi/gocept.pytestlayer [2] https://pypi.python.org/pypi/plone.testing#layers From holger at merlinux.eu Tue Apr 8 09:21:40 2014 From: holger at merlinux.eu (holger krekel) Date: Tue, 8 Apr 2014 07:21:40 +0000 Subject: [pytest-dev] Announcement: new maintainer for pytest-cov and cov-core In-Reply-To: References: Message-ID: <20140408072140.GX7198@merlinux.eu> Hi Marc, On Tue, Apr 08, 2014 at 09:01 +0200, Marc Schlaich wrote: > Hey, > > as the original author of these packages is unresponsive for almost two > years now, I requested maintainer status on PyPI ( > http://sourceforge.net/p/pypi/support-requests/352/). If anyone is > interested in (co-)maintaining any of these packages please get in touch. > I'm happy to share or transfer responsibility if someone is more suitable > than me. Thanks a lot for caring! > I'm considering moving the repositories to GitHub. What do you think about > that? Fine with me! > Additionally, I got maintainer status of nose-cov and nose2-cov (because > they are from the same author) but I'm not interested in actively > maintaining them. If someone is willing to take these over just let me know. Probably makes sense post this info to nose-dev (if you didn't already) and/or testing-in-python mailing list. One thing that i'd like to point out: pytest grew with 2.5 IIRC the ability to intercept pytest startup very early, before loading conftests, through the pytest_load_initial_conftests hook. It sees all options provided by core and setuptools-managed plugins and thus would allow pytest-cov to initiate coverage before conftest.py files (and before collection of course) and thus before project-specific code executes. This should give much better default output as modules imported from conftest files will be correctly included. For an example you can look at the _pytest/capture.py. best, holger > > Regards, Marc > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From holger at merlinux.eu Tue Apr 8 09:27:22 2014 From: holger at merlinux.eu (holger krekel) Date: Tue, 8 Apr 2014 07:27:22 +0000 Subject: [pytest-dev] Access fixtures from unittest.TestCase In-Reply-To: <20140408082000.65e456b5@widnar> References: <20140404112158.7d8b35a2@widnar> <20140407102427.GH7198@merlinux.eu> <20140407131831.15b49fac@widnar> <20140407112740.GP7198@merlinux.eu> <20140408082000.65e456b5@widnar> Message-ID: <20140408072722.GY7198@merlinux.eu> Hi Wolfgang, On Tue, Apr 08, 2014 at 08:20 +0200, Wolfgang Schnerring wrote: > Hello, > > > > Thanks for the hint! Using a method of the TestCase as a wrapper > > > fixture around the actual fixture is clever, but also a little > > > unwieldy... would there be an easy way to introduce an API to make > > > that easier? > > > > Thing is that trying to bring pytest fixtures to unittest.TestCase's > > methods directly is very hard, especially given the many > > extensions/subclasses that people use. > > Yeah, I can see how that might be a rather annoying proposition. > > On the other hand... I'm not too familiar with the pytest internals (yet? ;), > so this might be totally crazy, but would it be feasible to have an API like > pytest.get_fixture('myfixturename') to retrieve the fixture object? Or is there > no such kind of registry and they are all handled local to the test function? A global "pytest.get_fixture()" would be hard to get right, i am afraid. Indeed, all fixtures are local to test functions. pytest.get_fixture would need to be a function that works on a per-test basis, i.e. get changed (or it's context changed) for each test. You could probably write a local plugin that provides it. Basically setting item.getfuncargvalue as pytest.get_fixture in a pytest_runtest_setup hook. Parametrization wouldn't work with it for sure. > > do you have to inherit unittest.TestCase, btw? > > If you don't, all problems go away :) > > Yes I do; my use case is migrating projects with large test suites (several > thousand test functions across dozens of packages) from unittest/zope.testrunner > to pytest. Thus, we need mechanisms that work gradually, since anything that > requires us to change something /everywhere/ is a non-starter. > > We've already got fancy tooling[1] that converts zope.testrunner-style > "layers"[2] to pytest fixtures, but as you noted above, some test infrastructure > is hidden away in TestCase base classes. So, even if I start a new package > that uses pytest/fixtures from the ground up (as I did last week ;), > I still need to integrate with some older packages, and their TestCases. Thanks for explaining, makes sense. > But I guess I can work with the workaround you gave (using a TestCase method as > a fixture to wrap the actual fixture), while refactoring stuff piecemeal > to provide test infrastructure in a testframework-independent way > (you know, being testframework-indepent really isn't a use-case usually...) Yes, incremental refactoring like this is a good strategy. cheers and good luck, holger > Thanks again, > Wolfgang > > [1] https://pypi.python.org/pypi/gocept.pytestlayer > [2] https://pypi.python.org/pypi/plone.testing#layers > > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From anton7811 at gmail.com Tue Apr 15 18:47:16 2014 From: anton7811 at gmail.com (Anton P) Date: Tue, 15 Apr 2014 19:47:16 +0300 Subject: [pytest-dev] The issue with fixtures finalization Message-ID: Hi All, I found that pytest 2.5.2 doesn't finalize all fixtures. E.g. we have function and class level fixtures. In case func level fixture raises an exception, class level fixture finalization won't be called. SetupState._callfinalizers takes care only about finalizing of all fixtures with the same level. I didn't find any way to workaround this without modifying pytest code. Here is my fix: 1. add self.finalizer_exception=None attribute. 2. Modify _callfinalizers def _callfinalizers(self, colitem): finalizers = self._finalizers.pop(colitem, None) while finalizers: fin = finalizers.pop() try: fin() except (Exception, KeyboardInterrupt): # XXX Only first exception will be seen by user, # ideally all should be reported. if self.finalizer_exception is None: self.finalizer_exception = sys.exc_info() if self.finalizer_exception and not self._finalizers: py.builtin._reraise(*self.finalizer_exception) What do you think about this? Have I missed something? I assume that there could be another way to resolve the issue. Thank you in advance! Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianna.laugher at gmail.com Wed Apr 16 22:39:28 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 16 Apr 2014 16:39:28 -0400 Subject: [pytest-dev] Setting up tox Message-ID: Hello, The contributing guide ( http://pytest.org/latest/contributing.html ) is still missing a couple of steps I'm afraid... I installed tox in my virtualenv and then ran "python runtox.py -e py27,py33,flakes" as advised. At the end of the run tox tells me: ERROR: py27: could not install deps [nose, mock] ERROR: py33: InterpreterNotFound: python3.3 ERROR: flakes: could not install deps [pytest-flakes>=0.2] I can manually pip install nose, mock and pytest-flakes, but I don't know how to make python3.3 (which I have installed from my OS repo) "visible" or available to this virtualenv. Any ideas? Thanks, Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Wed Apr 16 22:44:37 2014 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Apr 2014 20:44:37 +0000 Subject: [pytest-dev] Setting up tox In-Reply-To: References: Message-ID: <20140416204437.GH7198@merlinux.eu> Hi Brianna, On Wed, Apr 16, 2014 at 16:39 -0400, Brianna Laugher wrote: > Hello, > > The contributing guide ( http://pytest.org/latest/contributing.html ) is > still missing a couple of steps I'm afraid... > > I installed tox in my virtualenv and then ran "python runtox.py -e > py27,py33,flakes" as advised. At the end of the run tox tells me: > > ERROR: py27: could not install deps [nose, mock] > ERROR: py33: InterpreterNotFound: python3.3 > ERROR: flakes: could not install deps [pytest-flakes>=0.2] > > I can manually pip install nose, mock and pytest-flakes, but I don't know > how to make python3.3 (which I have installed from my OS repo) "visible" or > available to this virtualenv. Any ideas? It should be on the PATH, so invoking "python3.3" should basically work. As to the "could not install deps" error, could you use the "-v" option and/or attach the full tox output log? best, holger > Thanks, > Brianna > > -- > They've just been waiting in a mountain for the right moment: > http://modernthings.org/ > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From brianna.laugher at gmail.com Wed Apr 16 22:56:11 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 16 Apr 2014 16:56:11 -0400 Subject: [pytest-dev] Setting up tox In-Reply-To: <20140416204437.GH7198@merlinux.eu> References: <20140416204437.GH7198@merlinux.eu> Message-ID: OK, I will do that. Another question, how can I build the docs? Brianna On 16 April 2014 16:44, holger krekel wrote: > Hi Brianna, > > On Wed, Apr 16, 2014 at 16:39 -0400, Brianna Laugher wrote: > > Hello, > > > > The contributing guide ( http://pytest.org/latest/contributing.html ) is > > still missing a couple of steps I'm afraid... > > > > I installed tox in my virtualenv and then ran "python runtox.py -e > > py27,py33,flakes" as advised. At the end of the run tox tells me: > > > > ERROR: py27: could not install deps [nose, mock] > > ERROR: py33: InterpreterNotFound: python3.3 > > ERROR: flakes: could not install deps [pytest-flakes>=0.2] > > > > I can manually pip install nose, mock and pytest-flakes, but I don't know > > how to make python3.3 (which I have installed from my OS repo) "visible" > or > > available to this virtualenv. Any ideas? > > It should be on the PATH, so invoking "python3.3" should basically work. > As to the "could not install deps" error, could you use the "-v" option > and/or attach the full tox output log? > > best, > holger > > > > Thanks, > > Brianna > > > > -- > > They've just been waiting in a mountain for the right moment: > > http://modernthings.org/ > > > _______________________________________________ > > Pytest-dev mailing list > > Pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Wed Apr 16 22:58:36 2014 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Apr 2014 20:58:36 +0000 Subject: [pytest-dev] Setting up tox In-Reply-To: References: <20140416204437.GH7198@merlinux.eu> Message-ID: <20140416205836.GJ7198@merlinux.eu> On Wed, Apr 16, 2014 at 16:56 -0400, Brianna Laugher wrote: > OK, I will do that. Another question, how can I build the docs? "tox -e doc" should work. Otherwise installing sphinx and going to "doc/en" and typing "make html" should work. Or on windows some sphinx-build command that you find in the tox.ini file. best, holger > Brianna > > On 16 April 2014 16:44, holger krekel wrote: > > > Hi Brianna, > > > > On Wed, Apr 16, 2014 at 16:39 -0400, Brianna Laugher wrote: > > > Hello, > > > > > > The contributing guide ( http://pytest.org/latest/contributing.html ) is > > > still missing a couple of steps I'm afraid... > > > > > > I installed tox in my virtualenv and then ran "python runtox.py -e > > > py27,py33,flakes" as advised. At the end of the run tox tells me: > > > > > > ERROR: py27: could not install deps [nose, mock] > > > ERROR: py33: InterpreterNotFound: python3.3 > > > ERROR: flakes: could not install deps [pytest-flakes>=0.2] > > > > > > I can manually pip install nose, mock and pytest-flakes, but I don't know > > > how to make python3.3 (which I have installed from my OS repo) "visible" > > or > > > available to this virtualenv. Any ideas? > > > > It should be on the PATH, so invoking "python3.3" should basically work. > > As to the "could not install deps" error, could you use the "-v" option > > and/or attach the full tox output log? > > > > best, > > holger > > > > > > > Thanks, > > > Brianna > > > > > > -- > > > They've just been waiting in a mountain for the right moment: > > > http://modernthings.org/ > > > > > _______________________________________________ > > > Pytest-dev mailing list > > > Pytest-dev at python.org > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > > -- > They've just been waiting in a mountain for the right moment: > http://modernthings.org/ > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From brianna.laugher at gmail.com Wed Apr 16 23:11:52 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 16 Apr 2014 17:11:52 -0400 Subject: [pytest-dev] Setting up tox In-Reply-To: <20140416205836.GJ7198@merlinux.eu> References: <20140416204437.GH7198@merlinux.eu> <20140416205836.GJ7198@merlinux.eu> Message-ID: Error logs from tox: https://gist.github.com/pfctdayelise/b8e4b249f3ae2b0103ab It seems like tox was happy to install sphinx when I built the docs. cheers Brianna On 16 April 2014 16:58, holger krekel wrote: > On Wed, Apr 16, 2014 at 16:56 -0400, Brianna Laugher wrote: > > OK, I will do that. Another question, how can I build the docs? > > "tox -e doc" should work. Otherwise installing sphinx and going > to "doc/en" and typing "make html" should work. Or on windows > some sphinx-build command that you find in the tox.ini file. > > best, > holger > > > > Brianna > > > > On 16 April 2014 16:44, holger krekel wrote: > > > > > Hi Brianna, > > > > > > On Wed, Apr 16, 2014 at 16:39 -0400, Brianna Laugher wrote: > > > > Hello, > > > > > > > > The contributing guide ( http://pytest.org/latest/contributing.html) is > > > > still missing a couple of steps I'm afraid... > > > > > > > > I installed tox in my virtualenv and then ran "python runtox.py -e > > > > py27,py33,flakes" as advised. At the end of the run tox tells me: > > > > > > > > ERROR: py27: could not install deps [nose, mock] > > > > ERROR: py33: InterpreterNotFound: python3.3 > > > > ERROR: flakes: could not install deps [pytest-flakes>=0.2] > > > > > > > > I can manually pip install nose, mock and pytest-flakes, but I don't > know > > > > how to make python3.3 (which I have installed from my OS repo) > "visible" > > > or > > > > available to this virtualenv. Any ideas? > > > > > > It should be on the PATH, so invoking "python3.3" should basically > work. > > > As to the "could not install deps" error, could you use the "-v" option > > > and/or attach the full tox output log? > > > > > > best, > > > holger > > > > > > > > > > Thanks, > > > > Brianna > > > > > > > > -- > > > > They've just been waiting in a mountain for the right moment: > > > > http://modernthings.org/ > > > > > > > _______________________________________________ > > > > Pytest-dev mailing list > > > > Pytest-dev at python.org > > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > > > > > > > -- > > They've just been waiting in a mountain for the right moment: > > http://modernthings.org/ > > > _______________________________________________ > > Pytest-dev mailing list > > Pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Wed Apr 16 23:16:39 2014 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Apr 2014 21:16:39 +0000 Subject: [pytest-dev] Setting up tox In-Reply-To: References: <20140416204437.GH7198@merlinux.eu> <20140416205836.GJ7198@merlinux.eu> Message-ID: <20140416211639.GK7198@merlinux.eu> On Wed, Apr 16, 2014 at 17:11 -0400, Brianna Laugher wrote: > Error logs from tox: > https://gist.github.com/pfctdayelise/b8e4b249f3ae2b0103ab > > It seems like tox was happy to install sphinx when I built the docs. Seems like "devpi.net" is having troubles providing the correct package or so currently (not sure why). It is used by "runtox.py". What happens if you delete the line in "runtox.py" containing "-i", "http:/..."? holger > cheers > Brianna > > > > On 16 April 2014 16:58, holger krekel wrote: > > > On Wed, Apr 16, 2014 at 16:56 -0400, Brianna Laugher wrote: > > > OK, I will do that. Another question, how can I build the docs? > > > > "tox -e doc" should work. Otherwise installing sphinx and going > > to "doc/en" and typing "make html" should work. Or on windows > > some sphinx-build command that you find in the tox.ini file. > > > > best, > > holger > > > > > > > Brianna > > > > > > On 16 April 2014 16:44, holger krekel wrote: > > > > > > > Hi Brianna, > > > > > > > > On Wed, Apr 16, 2014 at 16:39 -0400, Brianna Laugher wrote: > > > > > Hello, > > > > > > > > > > The contributing guide ( http://pytest.org/latest/contributing.html) is > > > > > still missing a couple of steps I'm afraid... > > > > > > > > > > I installed tox in my virtualenv and then ran "python runtox.py -e > > > > > py27,py33,flakes" as advised. At the end of the run tox tells me: > > > > > > > > > > ERROR: py27: could not install deps [nose, mock] > > > > > ERROR: py33: InterpreterNotFound: python3.3 > > > > > ERROR: flakes: could not install deps [pytest-flakes>=0.2] > > > > > > > > > > I can manually pip install nose, mock and pytest-flakes, but I don't > > know > > > > > how to make python3.3 (which I have installed from my OS repo) > > "visible" > > > > or > > > > > available to this virtualenv. Any ideas? > > > > > > > > It should be on the PATH, so invoking "python3.3" should basically > > work. > > > > As to the "could not install deps" error, could you use the "-v" option > > > > and/or attach the full tox output log? > > > > > > > > best, > > > > holger > > > > > > > > > > > > > Thanks, > > > > > Brianna > > > > > > > > > > -- > > > > > They've just been waiting in a mountain for the right moment: > > > > > http://modernthings.org/ > > > > > > > > > _______________________________________________ > > > > > Pytest-dev mailing list > > > > > Pytest-dev at python.org > > > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > > > > > > > > > > > > -- > > > They've just been waiting in a mountain for the right moment: > > > http://modernthings.org/ > > > > > _______________________________________________ > > > Pytest-dev mailing list > > > Pytest-dev at python.org > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > > -- > They've just been waiting in a mountain for the right moment: > http://modernthings.org/ > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From brianna.laugher at gmail.com Wed Apr 16 23:33:53 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 16 Apr 2014 17:33:53 -0400 Subject: [pytest-dev] Setting up tox In-Reply-To: <20140416211639.GK7198@merlinux.eu> References: <20140416204437.GH7198@merlinux.eu> <20140416205836.GJ7198@merlinux.eu> <20140416211639.GK7198@merlinux.eu> Message-ID: That worked...mostly. https://gist.github.com/pfctdayelise/b8e4b249f3ae2b0103ab#file-tox-output-without-devpi Is the "flakes: commands failed" something to worry about? ERROR: InvocationError: '/home/brianna/workspace/pytest/.tox/flakes/bin/py.test --flakes -m flakes _pytest testing' __________________________________________________________________________________________________ summary __________________________________________________________________________________________________ py27: commands succeeded ERROR: py33: InterpreterNotFound: python3.3 ERROR: flakes: commands failed Brianna On 16 April 2014 17:16, holger krekel wrote: > On Wed, Apr 16, 2014 at 17:11 -0400, Brianna Laugher wrote: > > Error logs from tox: > > https://gist.github.com/pfctdayelise/b8e4b249f3ae2b0103ab > > > > It seems like tox was happy to install sphinx when I built the docs. > > Seems like "devpi.net" is having troubles providing the correct package > or so currently (not sure why). It is used by "runtox.py". What > happens if you delete the line in "runtox.py" containing "-i", > "http:/..."? > > holger > > > cheers > > Brianna > > > > > > > > On 16 April 2014 16:58, holger krekel wrote: > > > > > On Wed, Apr 16, 2014 at 16:56 -0400, Brianna Laugher wrote: > > > > OK, I will do that. Another question, how can I build the docs? > > > > > > "tox -e doc" should work. Otherwise installing sphinx and going > > > to "doc/en" and typing "make html" should work. Or on windows > > > some sphinx-build command that you find in the tox.ini file. > > > > > > best, > > > holger > > > > > > > > > > Brianna > > > > > > > > On 16 April 2014 16:44, holger krekel wrote: > > > > > > > > > Hi Brianna, > > > > > > > > > > On Wed, Apr 16, 2014 at 16:39 -0400, Brianna Laugher wrote: > > > > > > Hello, > > > > > > > > > > > > The contributing guide ( > http://pytest.org/latest/contributing.html) is > > > > > > still missing a couple of steps I'm afraid... > > > > > > > > > > > > I installed tox in my virtualenv and then ran "python runtox.py > -e > > > > > > py27,py33,flakes" as advised. At the end of the run tox tells me: > > > > > > > > > > > > ERROR: py27: could not install deps [nose, mock] > > > > > > ERROR: py33: InterpreterNotFound: python3.3 > > > > > > ERROR: flakes: could not install deps [pytest-flakes>=0.2] > > > > > > > > > > > > I can manually pip install nose, mock and pytest-flakes, but I > don't > > > know > > > > > > how to make python3.3 (which I have installed from my OS repo) > > > "visible" > > > > > or > > > > > > available to this virtualenv. Any ideas? > > > > > > > > > > It should be on the PATH, so invoking "python3.3" should basically > > > work. > > > > > As to the "could not install deps" error, could you use the "-v" > option > > > > > and/or attach the full tox output log? > > > > > > > > > > best, > > > > > holger > > > > > > > > > > > > > > > > Thanks, > > > > > > Brianna > > > > > > > > > > > > -- > > > > > > They've just been waiting in a mountain for the right moment: > > > > > > http://modernthings.org/ > > > > > > > > > > > _______________________________________________ > > > > > > Pytest-dev mailing list > > > > > > Pytest-dev at python.org > > > > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > > > > > > > > > > > > > > > > > -- > > > > They've just been waiting in a mountain for the right moment: > > > > http://modernthings.org/ > > > > > > > _______________________________________________ > > > > Pytest-dev mailing list > > > > Pytest-dev at python.org > > > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > > > > > > > -- > > They've just been waiting in a mountain for the right moment: > > http://modernthings.org/ > > > _______________________________________________ > > Pytest-dev mailing list > > Pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Wed Apr 16 23:43:36 2014 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Apr 2014 21:43:36 +0000 Subject: [pytest-dev] Setting up tox In-Reply-To: References: <20140416204437.GH7198@merlinux.eu> Message-ID: <20140416214336.GL7198@merlinux.eu> On Wed, Apr 16, 2014 at 17:39 -0400, Brianna Laugher wrote: > On 16 April 2014 16:44, holger krekel wrote: > > > > > > I can manually pip install nose, mock and pytest-flakes, but I don't know > > > how to make python3.3 (which I have installed from my OS repo) "visible" > > or > > > available to this virtualenv. Any ideas? > > > > It should be on the PATH, so invoking "python3.3" should basically work. > > > > Do you mean calling runtox.py with the right python version? No luck there > either: > > (pytest)brianna at montreal:~/workspace/pytest$ which python3.4 > /usr/bin/python3.4 > (pytest)brianna at montreal:~/workspace/pytest$ python3.4 runtox.py -v -e > py27,py34,flakes > /usr/bin/python3.4: No module named tox > (pytest)brianna at montreal:~/workspace/pytest$ which python3 > /usr/bin/python3 > (pytest)brianna at montreal:~/workspace/pytest$ python3 runtox.py -v -e > py27,py34,flakes > /usr/bin/python3: No module named tox No, i mean that "python3.3" should be on the path because tox.ini defines that tests should work against the "py33" environment which implies a working "python3.3" interpreter. How you invoke "runtox.py" is a different thing and it does need tox installed in the interpreter you are invoking the script with. holger > Brianna > > -- > They've just been waiting in a mountain for the right moment: > http://modernthings.org/ From brianna.laugher at gmail.com Wed Apr 16 23:39:34 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 16 Apr 2014 17:39:34 -0400 Subject: [pytest-dev] Setting up tox In-Reply-To: <20140416204437.GH7198@merlinux.eu> References: <20140416204437.GH7198@merlinux.eu> Message-ID: On 16 April 2014 16:44, holger krekel wrote: > > > I can manually pip install nose, mock and pytest-flakes, but I don't know > > how to make python3.3 (which I have installed from my OS repo) "visible" > or > > available to this virtualenv. Any ideas? > > It should be on the PATH, so invoking "python3.3" should basically work. > Do you mean calling runtox.py with the right python version? No luck there either: (pytest)brianna at montreal:~/workspace/pytest$ which python3.4 /usr/bin/python3.4 (pytest)brianna at montreal:~/workspace/pytest$ python3.4 runtox.py -v -e py27,py34,flakes /usr/bin/python3.4: No module named tox (pytest)brianna at montreal:~/workspace/pytest$ which python3 /usr/bin/python3 (pytest)brianna at montreal:~/workspace/pytest$ python3 runtox.py -v -e py27,py34,flakes /usr/bin/python3: No module named tox Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianna.laugher at gmail.com Wed Apr 16 23:58:53 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Wed, 16 Apr 2014 17:58:53 -0400 Subject: [pytest-dev] Setting up tox In-Reply-To: <20140416214336.GL7198@merlinux.eu> References: <20140416204437.GH7198@merlinux.eu> <20140416214336.GL7198@merlinux.eu> Message-ID: On 16 April 2014 17:43, holger krekel wrote: > No, i mean that "python3.3" should be on the path because tox.ini > defines that tests should work against the "py33" environment which > implies a working "python3.3" interpreter. How you invoke "runtox.py" > is a different thing and it does need tox installed in the interpreter > you are invoking the script with. > So, what is the answer? 1) Install multiple pythons in a single virtualenv, somehow 2) Install tox system-wide, in which case how does it know about my development version of py.test? (from current working dir?) The contributing guide does say to install tox in the virtualenv. I am happy to update it...once I know what I am actually supposed to do. Brianna -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at merlinux.eu Thu Apr 17 00:56:05 2014 From: holger at merlinux.eu (holger krekel) Date: Wed, 16 Apr 2014 22:56:05 +0000 Subject: [pytest-dev] Setting up tox In-Reply-To: References: <20140416204437.GH7198@merlinux.eu> <20140416214336.GL7198@merlinux.eu> Message-ID: <20140416225605.GN7198@merlinux.eu> On Wed, Apr 16, 2014 at 17:58 -0400, Brianna Laugher wrote: > On 16 April 2014 17:43, holger krekel wrote: > > > No, i mean that "python3.3" should be on the path because tox.ini > > defines that tests should work against the "py33" environment which > > implies a working "python3.3" interpreter. How you invoke "runtox.py" > > is a different thing and it does need tox installed in the interpreter > > you are invoking the script with. > > > > So, what is the answer? > 1) Install multiple pythons in a single virtualenv, somehow no. You cannot really install multiple python version.. > 2) Install tox system-wide, in which case how does it know about my > development version of py.test? (from current working dir?) > The contributing guide does say to install tox in the virtualenv. I am > happy to update it...once I know what I am actually supposed to do. I usually install tox in a virtualenv itself. If i then run tox, it will create its own separate virtualenv environments and it uses the tox.ini-specified python interpreters for creating them. tox will then install pytest in those separate virtualenvs and then execute the commands specified in tox.ini. From your output it seems that this successfully worked for python2.7 but not for python3.3 and i suspected this is because "python3.3" is not in your PATH environment varaible and therefore tox cannot find it. hope this clarifies and sorry for failing to explain this more properly, holger > > Brianna > > -- > They've just been waiting in a mountain for the right moment: > http://modernthings.org/ > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From flub at devork.be Thu Apr 17 10:38:52 2014 From: flub at devork.be (Floris Bruynooghe) Date: Thu, 17 Apr 2014 09:38:52 +0100 Subject: [pytest-dev] Setting up tox In-Reply-To: References: <20140416204437.GH7198@merlinux.eu> <20140416214336.GL7198@merlinux.eu> Message-ID: On 16 April 2014 22:58, Brianna Laugher wrote: > So, what is the answer? > 1) Install multiple pythons in a single virtualenv, somehow The multiple python's need to be on the system, system wide installs are fine. Personally I use the system provided ones plus, on ubuntu, the deadsnakes ppa for all other python versions. On my Debian boxes I build the other versions from scratch. But most systems ship with a 2.x and a 3.x version by now which is a good enough start. > 2) Install tox system-wide, in which case how does it know about my > development version of py.test? (from current working dir?) Contrary to Holger I tend to install tox in my system's python using "pip install -U --user tox" and use that to run the py.test tests. It works with the current working dir to find the package under test indeed, then it packs it up and deploys it in a few virtualenvs it manages itself. Hope that helps, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From msabramo at gmail.com Thu Apr 17 03:17:35 2014 From: msabramo at gmail.com (Marc Abramowitz) Date: Wed, 16 Apr 2014 18:17:35 -0700 Subject: [pytest-dev] Setting up tox In-Reply-To: <20140416225605.GN7198@merlinux.eu> References: <20140416204437.GH7198@merlinux.eu> <20140416214336.GL7198@merlinux.eu> <20140416225605.GN7198@merlinux.eu> Message-ID: In order to fix the python3.3 error, you just need to get it so that "python3.3" works normally from the shell. First, Python 3.3 needs to be installed. Tox doesn't install the Pythons for you, like say, pythonbrew. I don't know what distro you're on, but for Ubuntu, I typically set up the "deadsnakes" PPA ( https://launchpad.net/~fkrull/+archive/deadsnakes) and then I can `sudo apt-get install python3.3-dev`. The steps look something like this on Ubuntu: sudo apt-get install python-software-properties # This is to get add-apt-repository, which you may or may not already have sudo add-apt-repository ppa:fkrull/deadsnakes sudo apt-get update sudo apt-get install python3.3-dev Of course, I'm just guessing that you might have Ubuntu because it's popular. If I'm wrong, the steps will be completely different. If you have a different distro, you can Google around or maybe post again and maybe someone else can tell you how they do it. Also, "python3.3" needs to be in $PATH. Most likely if you install with a package manager like apt-get or yum, it will be automatically in the $PATH. It might not be if you build from source. On Wed, Apr 16, 2014 at 3:56 PM, holger krekel wrote: > On Wed, Apr 16, 2014 at 17:58 -0400, Brianna Laugher wrote: > > On 16 April 2014 17:43, holger krekel wrote: > > > > > No, i mean that "python3.3" should be on the path because tox.ini > > > defines that tests should work against the "py33" environment which > > > implies a working "python3.3" interpreter. How you invoke "runtox.py" > > > is a different thing and it does need tox installed in the interpreter > > > you are invoking the script with. > > > > > > > So, what is the answer? > > 1) Install multiple pythons in a single virtualenv, somehow > > no. You cannot really install multiple python version.. > > > 2) Install tox system-wide, in which case how does it know about my > > development version of py.test? (from current working dir?) > > > The contributing guide does say to install tox in the virtualenv. I am > > happy to update it...once I know what I am actually supposed to do. > > I usually install tox in a virtualenv itself. If i then run tox, it > will create its own separate virtualenv environments and it uses the > tox.ini-specified python interpreters for creating them. tox will > then install pytest in those separate virtualenvs and then execute > the commands specified in tox.ini. From your output it seems that > this successfully worked for python2.7 but not for python3.3 and i > suspected this is because "python3.3" is not in your PATH environment > varaible and therefore tox cannot find it. > > hope this clarifies and sorry for failing to explain this more properly, > holger > > > > > > Brianna > > > > -- > > They've just been waiting in a mountain for the right moment: > > http://modernthings.org/ > > > _______________________________________________ > > 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 brianna.laugher at gmail.com Thu Apr 17 15:49:40 2014 From: brianna.laugher at gmail.com (Brianna Laugher) Date: Thu, 17 Apr 2014 09:49:40 -0400 Subject: [pytest-dev] Setting up tox In-Reply-To: References: <20140416204437.GH7198@merlinux.eu> <20140416214336.GL7198@merlinux.eu> Message-ID: OK with a fresh head this morning... it was PEBCAK as usual. I had installed python3 (which was3.2) and python3.4, but not python3.3. Now I have installed python3.3 all is working as advertised. Sorry for the confusion and thanks everyone for your help. Brianna On 17 April 2014 04:38, Floris Bruynooghe wrote: > On 16 April 2014 22:58, Brianna Laugher wrote: > > So, what is the answer? > > 1) Install multiple pythons in a single virtualenv, somehow > > The multiple python's need to be on the system, system wide installs > are fine. Personally I use the system provided ones plus, on ubuntu, > the deadsnakes ppa for all other python versions. On my Debian boxes > I build the other versions from scratch. But most systems ship with a > 2.x and a 3.x version by now which is a good enough start. > > > 2) Install tox system-wide, in which case how does it know about my > > development version of py.test? (from current working dir?) > > Contrary to Holger I tend to install tox in my system's python using > "pip install -U --user tox" and use that to run the py.test tests. It > works with the current working dir to find the package under test > indeed, then it packs it up and deploys it in a few virtualenvs it > manages itself. > > > Hope that helps, > Floris > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > -- They've just been waiting in a mountain for the right moment: http://modernthings.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From petrovi4.alexander at gmail.com Mon Apr 21 20:12:40 2014 From: petrovi4.alexander at gmail.com (Alexander Petrovich) Date: Mon, 21 Apr 2014 21:12:40 +0300 Subject: [pytest-dev] Using print statements in pytest's teardown_method() Message-ID: Is there any way to get them actually printed? I use pytest to run my selenium tests and I got some test failure information printed in teardown, such as fail url, fail screenshot, user, etc. But I can't find any way to get them printed. Could you suggest something, please? -- With best regards, Petrovich Alexander QA Automation Engineer Smartweb Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: From petrovi4.alexander at gmail.com Tue Apr 22 13:10:06 2014 From: petrovi4.alexander at gmail.com (Alexander Petrovich) Date: Tue, 22 Apr 2014 14:10:06 +0300 Subject: [pytest-dev] Print statements in teardown_method(self, method) Message-ID: Is there any way to get them actually printed? I use pytest to run my selenium tests and I got some test failure information printed in teardown, such as fail url, fail screenshot path, user, etc. But I can't find any way to get them printed. Could you suggest something, please? -- With best regards, Petrovich Alexander QA Automation Engineer Smartweb Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: From mount.sarah at gmail.com Fri Apr 25 02:01:37 2014 From: mount.sarah at gmail.com (Sarah Mount) Date: Fri, 25 Apr 2014 01:01:37 +0100 Subject: [pytest-dev] py.test and decorators In-Reply-To: References: <20140123180814.GU22354@merlinux.eu> <20140123183008.GW22354@merlinux.eu> Message-ID: Hi Floris, Sorry for the very long delay, but I wanted to follow this up, mainly just to say thank you for your reply, which was extremely helpful. You were right that I had not used fixtures appropriately and your fix of creating a fixture to produce channel objects works fine. I'm still not sure whether my original code showed up a bug in py.test or not, I'm guessing probably not and the problem was at my end. However, if there's anything else I can do to help shed some light on it please let me know. Regards, Sarah On Thu, Feb 20, 2014 at 9:46 PM, Floris Bruynooghe wrote: > Hi Sarah, > > Apologies for not responding before, I wasn't really following this > thread however Holger is away for a month hence the long silence I > guess. > > I've used the zip and followed the instructions. As an example I've > started with uncommenting testpoison and indeed as soon as uncommented > py.test failed weirdly without any hint: while executing the test it > just exited. I can't say exactly what is going on there and it > probably is a bug that py.test just exists, but without narrowing it > down it's hard to say why (and all the * imports make it hard to > follow what's going on ;-)). > > However I assumed that this test was supposed to get a Channel > instance from a fixture. Not finding any fixtures I changed the code > to this: > > @pytest.fixture > def chan(): > return Channel() > > @process > def testpoinson(chan): > print('Sending termination event...') > chan.poison() > return > > And now running the tests works just fine. > > Having the @process decorator on the test function is a bit odd > however and I'm not sure how this behaves. It's probably better to > try writing tests without a decorator. E.g. the following worked as > well and looks much more reasonable to me (I'm just guessing here on > the csp stuff btw, maybe I'm doing silly things): > > @pytest.fixture > def chan(): > return Channel() > > def test_poinson(chan): > @process > def testpoison(chan): > # chan = Channel() > print('Sending termination event...') > chan.poison() > return > ret = testpoison(chan) > assert ret > > > I don't really feel like I understand your problem, for example I feel > like this test needs to assert something on the channel but I have no > idea how/what (some process seems to be started anyway when I add > ``print ret; assert 0``). But maybe this was enough to give you some > inspiration of how to prod things to start making some progress again. > > Regards, > Floris > > On 17 February 2014 09:16, Sarah Mount wrote: > > Sorry to be a pain, I realise everyone here is a volunteer, but is there > a > > way to move this issue forward? I have quite a bit of work blocked on > > getting py.test to work on my repo currently, and I'd rather use py.test > > than any other framework. I'm more than happy to put in more effort to > > narrow the bug down or take some of the next steps myself, but at this > stage > > I'm not really sure where to start... > > > > Thanks, > > > > Sarah > > > > > > On Fri, Jan 24, 2014 at 9:35 AM, Sarah Mount > wrote: > >> > >> On 1/23/14, holger krekel wrote: > >> > On Thu, Jan 23, 2014 at 18:27 +0000, Sarah Mount wrote: > >> >> The tests were completely ad-hoc and did not use unittest or any > other > >> >> library. They had a hand-rolled runner which ran all the functions > like > >> >> test_one_one from a script. > >> >> > >> >> The odd thing is that Python 2.7 + py.test + the functools.wraps > >> >> version > >> >> of > >> >> the decorators worked OK. > >> >> > >> >> Could it be that I have inadvertently turned the logging module on > and > >> >> output from that is confusing the py.test runner? > >> > > >> > wouldn't think so. Can you attach a zip file and state the > dependencies > >> > so we can try to reproduce? Or a repo-url? > >> > > >> > >> Many thanks, I am reluctant to give you a repo-url since there is so > >> much code in there that is irrelevant to this issue it would be hard > >> to figure out what is going on. > >> > >> The attached zip contains the minimum code to reproduce. If you run > >> "show_bug.sh" from the pytest-bug directory this will: > >> > >> 1) install the requirements via pip, > >> > >> 2) run a single test from vanilla python (should pass), > >> > >> 3) run the same test with py.test (should green at this stage) and > >> > >> 4) display some text explaining what to uncomment to reproduce the bug. > >> > >> I have narrowed it down quite a bit, and it turns out that if you > >> comment out most of the code in base.py everything works just fine... > >> which is odd. > >> > >> Thanks for your help, > >> > >> Sarah > >> > >> -- > >> Sarah Mount, Senior Lecturer, University of Wolverhampton > >> website: http://www.snim2.org/ > >> twitter: @snim2 > > > > > > > > > > -- > > Sarah Mount, Senior Lecturer, University of Wolverhampton > > website: http://www.snim2.org/ > > twitter: @snim2 > > > > _______________________________________________ > > Pytest-dev mailing list > > Pytest-dev at python.org > > https://mail.python.org/mailman/listinfo/pytest-dev > > > > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > -- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From msabramo at gmail.com Wed Apr 23 23:08:03 2014 From: msabramo at gmail.com (Marc Abramowitz) Date: Wed, 23 Apr 2014 14:08:03 -0700 Subject: [pytest-dev] Print statements in teardown_method(self, method) In-Reply-To: References: Message-ID: Did you try `py.test -s`. The -s option prevents the capture of stdout. On Tue, Apr 22, 2014 at 4:10 AM, Alexander Petrovich < petrovi4.alexander at gmail.com> wrote: > Is there any way to get them actually printed? I use pytest to run my > selenium tests and I got some test failure information printed in teardown, > such as fail url, fail screenshot path, user, etc. But I can't find any way > to get them printed. Could you suggest something, please? > > -- > With best regards, > Petrovich Alexander > QA Automation Engineer > Smartweb Consulting > > _______________________________________________ > 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 Mon Apr 28 09:22:40 2014 From: holger at merlinux.eu (holger krekel) Date: Mon, 28 Apr 2014 07:22:40 +0000 Subject: [pytest-dev] 2.6 / please help with remaining bugs Message-ID: <20140428072240.GD1151@merlinux.eu> Hi all, i'd like to go for a 2.6 release in May. There are 16 reported bugs in pytest core remaining, however: https://bitbucket.org/hpk42/pytest/issues?component=&kind=bug&status=open&status=new Could some of you help and assign issues to yourself and see about fixing or discussing them? I will focus on reviewing issue comments and PRs but also try to come up with fixes myself. thanks and best, holger From flub at devork.be Mon Apr 28 21:36:03 2014 From: flub at devork.be (Floris Bruynooghe) Date: Mon, 28 Apr 2014 20:36:03 +0100 Subject: [pytest-dev] 2.6 / please help with remaining bugs In-Reply-To: <20140428072240.GD1151@merlinux.eu> References: <20140428072240.GD1151@merlinux.eu> Message-ID: On 28 April 2014 08:22, holger krekel wrote: > Could some of you help and assign issues to yourself and see > about fixing or discussing them? For the record I'm interested in "#507: Assertion breaks with dictionary comprehention" but don't quite feel comfortable enough to assign it to me just yet :-) -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From benjamin at python.org Mon Apr 28 22:47:53 2014 From: benjamin at python.org (Benjamin Peterson) Date: Mon, 28 Apr 2014 13:47:53 -0700 Subject: [pytest-dev] 2.6 / please help with remaining bugs In-Reply-To: References: <20140428072240.GD1151@merlinux.eu> Message-ID: <1398718073.31717.111404233.0256B81A@webmail.messagingengine.com> On Mon, Apr 28, 2014, at 12:36, Floris Bruynooghe wrote: > On 28 April 2014 08:22, holger krekel wrote: > > Could some of you help and assign issues to yourself and see > > about fixing or discussing them? > > For the record I'm interested in "#507: Assertion breaks with > dictionary comprehention" but don't quite feel comfortable enough to > assign it to me just yet :-) I can look. From holger at merlinux.eu Tue Apr 29 10:28:17 2014 From: holger at merlinux.eu (holger krekel) Date: Tue, 29 Apr 2014 08:28:17 +0000 Subject: [pytest-dev] pytest logo / comments welcome Message-ID: <20140429082817.GP1151@merlinux.eu> Hi all, am thinking of providing pytest with a logo finally ... gets about time after all those years i guess :) My plan is to go for 99designs and guarantee some 250 euros for the final logo. There are a few questions they want as background where i'd like to hear opinions :) - should it be a little animal? should it be abstract? - should it contain the text "pytest" or "py.test" or nothing? - should it have snakes? - should it have a goat in some way in it? - any colors you'd prefer? - any testing tool related logos you like? happy about any comments/feedback as i feel a bit overwhelmed :) best, holger From mail at florian-schulze.net Tue Apr 29 11:26:09 2014 From: mail at florian-schulze.net (Florian Schulze) Date: Tue, 29 Apr 2014 11:26:09 +0200 Subject: [pytest-dev] pytest logo / comments welcome In-Reply-To: <20140429082817.GP1151@merlinux.eu> References: <20140429082817.GP1151@merlinux.eu> Message-ID: On 29 Apr 2014, at 10:28, holger krekel wrote: > My plan is to go for 99designs and guarantee some 250 euros for the > final logo. There are a few questions they want as background where > i'd > like to hear opinions :) I looked a bit around on the page and I don't see how the designer side of things really works. Do designers get money for drafts, or only for the final design? If the latter, then I think this exploits the designers. They would then do stuff for free in the hope to get paid. Just something to consider. > - should it be a little animal? should it be abstract? I would say abstract ones are often simpler, but especially in regard to testing no ideas would come to my mind at least. > - should it contain the text "pytest" or "py.test" or nothing? I would tend to "py.test". > - should it have snakes? > > - should it have a goat in some way in it? If animals are used, then they should be very stylized, so the logo works with few or only one color as well. > - any colors you'd prefer? Maybe fitting to the current docs. > - any testing tool related logos you like? No idea. Regards, Florian Schulze From holger at merlinux.eu Tue Apr 29 11:46:46 2014 From: holger at merlinux.eu (holger krekel) Date: Tue, 29 Apr 2014 09:46:46 +0000 Subject: [pytest-dev] pytest logo / comments welcome In-Reply-To: References: <20140429082817.GP1151@merlinux.eu> Message-ID: <20140429094646.GR1151@merlinux.eu> On Tue, Apr 29, 2014 at 11:26 +0200, Florian Schulze wrote: > On 29 Apr 2014, at 10:28, holger krekel wrote: > > >My plan is to go for 99designs and guarantee some 250 euros for the > >final logo. There are a few questions they want as background > >where i'd > >like to hear opinions :) > > I looked a bit around on the page and I don't see how the designer > side of things really works. Do designers get money for drafts, or > only for the final design? If the latter, then I think this exploits > the designers. They would then do stuff for free in the hope to get > paid. Just something to consider. they only get money for final designs. If anyone has a better site to use please let me know. > >- should it be a little animal? should it be abstract? > > I would say abstract ones are often simpler, but especially in > regard to testing no ideas would come to my mind at least. > > >- should it contain the text "pytest" or "py.test" or nothing? > > I would tend to "py.test". > > >- should it have snakes? > > > >- should it have a goat in some way in it? > > If animals are used, then they should be very stylized, so the logo > works with few or only one color as well. > > >- any colors you'd prefer? > > Maybe fitting to the current docs. > > >- any testing tool related logos you like? > > No idea. thanks for getting back. Tarek brought up the idea of a "pan flute" see e.g. https://en.wikipedia.org/wiki/Pan_flute because it is used to herd goats and goats are the inofficial mascott of python testing. Also multiple pipes convey the idea of parallel testing ... I kind of like that. holger > Regards, > Florian Schulze > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > From lac at openend.se Tue Apr 29 13:29:55 2014 From: lac at openend.se (Laura Creighton) Date: Tue, 29 Apr 2014 13:29:55 +0200 Subject: [pytest-dev] pytest logo / comments welcome In-Reply-To: Message from holger krekel of "Tue, 29 Apr 2014 08:28:17 -0000." <20140429082817.GP1151@merlinux.eu> References: <20140429082817.GP1151@merlinux.eu> Message-ID: <201404291129.s3TBTtQF027888@fido.openend.se> * should look good on a hoodie/t-shirt From holger at merlinux.eu Wed Apr 30 12:02:35 2014 From: holger at merlinux.eu (holger krekel) Date: Wed, 30 Apr 2014 10:02:35 +0000 Subject: [pytest-dev] Using print statements in pytest's teardown_method() In-Reply-To: References: Message-ID: <20140430100235.GG1151@merlinux.eu> On Mon, Apr 21, 2014 at 21:12 +0300, Alexander Petrovich wrote: > Is there any way to get them actually printed? I use pytest to run my > selenium tests and I got some test failure information printed in teardown, > such as fail url, fail screenshot, user, etc. But I can't find any way to > get them printed. Could you suggest something, please? A teardown hook or a fixture finalizer is indeed not useful. I can think only of adding a pytest_pyfunc_call hook to a conftest.py file which wraps test execution and prints some extra information which is then shown in the captured output in the failure output. Can try to post an example if you need it but am a bit too busy to do it immediately. best, holger > -- > With best regards, > Petrovich Alexander > QA Automation Engineer > Smartweb Consulting > _______________________________________________ > Pytest-dev mailing list > Pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev From flub at devork.be Wed Apr 30 12:48:19 2014 From: flub at devork.be (Floris Bruynooghe) Date: Wed, 30 Apr 2014 11:48:19 +0100 Subject: [pytest-dev] pytest logo / comments welcome In-Reply-To: <20140429082817.GP1151@merlinux.eu> References: <20140429082817.GP1151@merlinux.eu> Message-ID: On 29 April 2014 09:28, holger krekel wrote: > - should it be a little animal? should it be abstract? I'd be -1 on an animal I guess. The pan pipes thing might be good. > - should it contain the text "pytest" or "py.test" or nothing? Either "py.test" or nothing I reckon > - should it have a goat in some way in it? Probably not, but it seems that's already resolved. > - any colors you'd prefer? Maybe blue & yellow from the python logo? All of this IMHO obviously. Regards, Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From variedthoughts at gmail.com Wed Apr 30 22:55:56 2014 From: variedthoughts at gmail.com (Brian Okken) Date: Wed, 30 Apr 2014 13:55:56 -0700 Subject: [pytest-dev] pytest logo / comments welcome In-Reply-To: <20140429082817.GP1151@merlinux.eu> References: <20140429082817.GP1151@merlinux.eu> Message-ID: > - should it be a little animal? should it be abstract? not an animal > - should it contain the text "pytest" or "py.test" or nothing? no opinion > - should it have snakes? I'm tired of the snake theme. It works for the python logo, but everywhere else I've seen it, meh. > - should it have a goat in some way in it? Hmmm. First reaction was "no". However, if it were a stylized goat in some way similar to the stylized snakes of python, it might work. > - any colors you'd prefer? I've always thought of unittest as business-beige, like an old IBM. And pytest as royal purple. No idea why though. On Tue, Apr 29, 2014 at 1:28 AM, holger krekel wrote: > Hi all, > > am thinking of providing pytest with a logo finally ... gets about > time after all those years i guess :) > > My plan is to go for 99designs and guarantee some 250 euros for the > final logo. There are a few questions they want as background where i'd > like to hear opinions :) > > - should it be a little animal? should it be abstract? > > - should it contain the text "pytest" or "py.test" or nothing? > > - should it have snakes? > > - should it have a goat in some way in it? > > - any colors you'd prefer? > > - any testing tool related logos you like? > > happy about any comments/feedback as i feel a bit overwhelmed :) > > best, > holger > > _______________________________________________ > 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 lahwran0 at gmail.com Wed Apr 30 23:16:55 2014 From: lahwran0 at gmail.com (lahwran) Date: Wed, 30 Apr 2014 15:16:55 -0600 Subject: [pytest-dev] pytest logo / comments welcome In-Reply-To: <20140429082817.GP1151@merlinux.eu> References: <20140429082817.GP1151@merlinux.eu> Message-ID: I think monty python references are under-done in the python community, considering its namesake; perhaps something based on that? On Tue, Apr 29, 2014 at 2:28 AM, holger krekel wrote: > Hi all, > > am thinking of providing pytest with a logo finally ... gets about > time after all those years i guess :) > > My plan is to go for 99designs and guarantee some 250 euros for the > final logo. There are a few questions they want as background where i'd > like to hear opinions :) > > - should it be a little animal? should it be abstract? > > - should it contain the text "pytest" or "py.test" or nothing? > > - should it have snakes? > > - should it have a goat in some way in it? > > - any colors you'd prefer? > > - any testing tool related logos you like? > > happy about any comments/feedback as i feel a bit overwhelmed :) > > best, > holger > > _______________________________________________ > 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: