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 <f...@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.sa...@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.sa...@gmail.com>
> wrote:
> >>
> >> On 1/23/14, holger krekel <hol...@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
>
--
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
