Hi there, I am currently converting some very idiosyncratic hand-rolled tests into more sensible unit tests with pytest. I had a problem running tests which dealt with decorators and following the advice here: http://stackoverflow.com/questions/19614658/how-do-i-make-pytest-fixtures-wo... I refactored all my decorators to use the decorator library rather than functools.wraps. The win there was that now the Python 2.7 version of my code behaves in the same way as the Python 3.3 code (whereas before the 2.7 code passed and the 3.3 code errored). The fail is that now none of the tests run at all! I tried running tests without py.test (as in: python -m mylib.test.test_one) and they ran as expected. If I try to use the library just from a REPL session it seems OK. I suspect that the issue has occurred because I haven't yet understood where to use pytest fixtures. The (simplified) code looks roughly like this: ### FILE base.py @process def foo(channel): channel.write(100) @process def bar(channel): channel.read() ### FILE test_one.py def test_one_one(): channel = Channel() par(foo(channel), bar(channel)).start() And the results look like this: $ py.test mylib/ ================================================================ test session starts ================================================================= platform linux2 -- Python 2.7.5 -- pytest-2.5.1 collected 44 items mylib/test/test_one.py (venv)$ I have tried putting the @pytest.fixture decorator on both the functions in base.py and those in test_one.py but neither works. Any ideas? Thanks, Sarah -- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
Hi Sarah, On Wed, Jan 22, 2014 at 21:21 +0000, Sarah Mount wrote:
Hi there,
I am currently converting some very idiosyncratic hand-rolled tests into more sensible unit tests with pytest. I had a problem running tests which dealt with decorators and following the advice here:
http://stackoverflow.com/questions/19614658/how-do-i-make-pytest-fixtures-wo...
I refactored all my decorators to use the decorator library rather than functools.wraps.
The win there was that now the Python 2.7 version of my code behaves in the same way as the Python 3.3 code (whereas before the 2.7 code passed and the 3.3 code errored). The fail is that now none of the tests run at all!
I tried running tests without py.test (as in: python -m mylib.test.test_one) and they ran as expected. If I try to use the library just from a REPL session it seems OK. I suspect that the issue has occurred because I haven't yet understood where to use pytest fixtures.
The (simplified) code looks roughly like this:
### FILE base.py
@process def foo(channel): channel.write(100)
@process def bar(channel): channel.read()
### FILE test_one.py
def test_one_one(): channel = Channel() par(foo(channel), bar(channel)).start()
Could you post the code that runs under the unittests framework as well? The test looks OK, maybe "py.test -s mylib" (don't capture output) would give a clue why the test run bails out the way it does. best, holger
And the results look like this:
$ py.test mylib/ ================================================================ test session starts ================================================================= platform linux2 -- Python 2.7.5 -- pytest-2.5.1 collected 44 items
mylib/test/test_one.py (venv)$
I have tried putting the @pytest.fixture decorator on both the functions in base.py and those in test_one.py but neither works.
Any ideas?
Thanks,
Sarah
-- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
_______________________________________________ Pytest-dev mailing list Pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
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? Thanks, Sarah On Thu, Jan 23, 2014 at 6:08 PM, holger krekel <holger@merlinux.eu> wrote:
Hi Sarah,
On Wed, Jan 22, 2014 at 21:21 +0000, Sarah Mount wrote:
Hi there,
I am currently converting some very idiosyncratic hand-rolled tests into more sensible unit tests with pytest. I had a problem running tests which dealt with decorators and following the advice here:
http://stackoverflow.com/questions/19614658/how-do-i-make-pytest-fixtures-wo...
I refactored all my decorators to use the decorator library rather than functools.wraps.
The win there was that now the Python 2.7 version of my code behaves in
same way as the Python 3.3 code (whereas before the 2.7 code passed and
3.3 code errored). The fail is that now none of the tests run at all!
I tried running tests without py.test (as in: python -m mylib.test.test_one) and they ran as expected. If I try to use the
the the library
just from a REPL session it seems OK. I suspect that the issue has occurred because I haven't yet understood where to use pytest fixtures.
The (simplified) code looks roughly like this:
### FILE base.py
@process def foo(channel): channel.write(100)
@process def bar(channel): channel.read()
### FILE test_one.py
def test_one_one(): channel = Channel() par(foo(channel), bar(channel)).start()
Could you post the code that runs under the unittests framework as well?
The test looks OK, maybe "py.test -s mylib" (don't capture output) would give a clue why the test run bails out the way it does.
best, holger
And the results look like this:
$ py.test mylib/ ================================================================ test session starts ================================================================= platform linux2 -- Python 2.7.5 -- pytest-2.5.1 collected 44 items
mylib/test/test_one.py (venv)$
I have tried putting the @pytest.fixture decorator on both the functions
in
base.py and those in test_one.py but neither works.
Any ideas?
Thanks,
Sarah
-- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
_______________________________________________ Pytest-dev mailing list Pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
-- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
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? holger
Thanks,
Sarah
On Thu, Jan 23, 2014 at 6:08 PM, holger krekel <holger@merlinux.eu> wrote:
Hi Sarah,
On Wed, Jan 22, 2014 at 21:21 +0000, Sarah Mount wrote:
Hi there,
I am currently converting some very idiosyncratic hand-rolled tests into more sensible unit tests with pytest. I had a problem running tests which dealt with decorators and following the advice here:
http://stackoverflow.com/questions/19614658/how-do-i-make-pytest-fixtures-wo...
I refactored all my decorators to use the decorator library rather than functools.wraps.
The win there was that now the Python 2.7 version of my code behaves in
same way as the Python 3.3 code (whereas before the 2.7 code passed and
3.3 code errored). The fail is that now none of the tests run at all!
I tried running tests without py.test (as in: python -m mylib.test.test_one) and they ran as expected. If I try to use the
the the library
just from a REPL session it seems OK. I suspect that the issue has occurred because I haven't yet understood where to use pytest fixtures.
The (simplified) code looks roughly like this:
### FILE base.py
@process def foo(channel): channel.write(100)
@process def bar(channel): channel.read()
### FILE test_one.py
def test_one_one(): channel = Channel() par(foo(channel), bar(channel)).start()
Could you post the code that runs under the unittests framework as well?
The test looks OK, maybe "py.test -s mylib" (don't capture output) would give a clue why the test run bails out the way it does.
best, holger
And the results look like this:
$ py.test mylib/ ================================================================ test session starts ================================================================= platform linux2 -- Python 2.7.5 -- pytest-2.5.1 collected 44 items
mylib/test/test_one.py (venv)$
I have tried putting the @pytest.fixture decorator on both the functions
in
base.py and those in test_one.py but neither works.
Any ideas?
Thanks,
Sarah
-- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
_______________________________________________ Pytest-dev mailing list Pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
-- Sarah Mount, Senior Lecturer, University of Wolverhampton website: http://www.snim2.org/ twitter: @snim2
On 1/23/14, holger krekel <holger@merlinux.eu> 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
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 <mount.sarah@gmail.com> wrote:
On 1/23/14, holger krekel <holger@merlinux.eu> 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
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 <mount.sarah@gmail.com> 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 <mount.sarah@gmail.com> wrote:
On 1/23/14, holger krekel <holger@merlinux.eu> 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@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
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 <flub@devork.be> 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
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 <mount.sarah@gmail.com> wrote:
On 1/23/14, holger krekel <holger@merlinux.eu> 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
On 17 February 2014 09:16, Sarah Mount <mount.sarah@gmail.com> wrote: 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@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
participants (3)
-
Floris Bruynooghe -
holger krekel -
Sarah Mount