[pytest-dev] py.test and decorators

Sarah Mount mount.sarah at gmail.com
Fri Apr 25 02:01:37 CEST 2014


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 at 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
>
> On 17 February 2014 09:16, Sarah Mount <mount.sarah at 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 at gmail.com>
> wrote:
> >>
> >> On 1/23/14, holger krekel <holger at 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 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: <http://mail.python.org/pipermail/pytest-dev/attachments/20140425/402e139d/attachment.html>


More information about the Pytest-dev mailing list