Mailman 3 April 2009 - pytest-dev

[py-dev] py.test : setup / teardown at the directory level
by Philippe Fremy April 16, 2010

April 16, 2010

Hi, I was wondering if there is a possibility to have or emulate setup/teardown method for an entire directory of tests ? I have an expensive setup/teardown method, which I share through about 10 modules, each with about 20 tests. I would save time if I could do the setup/teardown just for that directory. cheers, Philippe

3 9

Re: [py-dev] Gitting rid of "(inconsistently failed then succeeded)" ?
by Laura Creighton May 4, 2009

May 4, 2009

In a message of Tue, 28 Apr 2009 13:40:36 +0200, holger krekel writes: <snip> >taking your valid points into account, i'd >i'd like to go with something like this (re-posting the func example): > > def test_inconsistent(): > def f(l=[1,0]): return l.pop() >> assert f() >E: AssertionError: (assertion failed, but when it was re-run for >printing intermediate values, it did not fail. Suggestions: >compute assert expression before the assert or use --nomagic) > >fine to you? >thanks & cheers, >holger Looks great to me. :) Laura

3 2

[py-dev] Keyboard interrupt causes unclean shutdown in py.test & py.execnet
by Simon April 30, 2009

April 30, 2009

This actually looks like an execnet issue, or maybe I'm not quite understanding how this should work. If I run the following code, I get a bunch of stuff left over. Aside from the ssh and shell instances, the main problem appears to be the python exec instance on the remote machine (in this example 'localhost'). If this process is killed, everything else seems to sort itself out. Calling the exit() method of the gateway doesn't seem to help. Nor does calling the close() method on the channel instance. ======================================= cmd = """ while True: pass """ import py g=py.execnet.SshGateway("localhost") c=g.remote_exec(cmd) ======================================= Simon

3 7

Re: [py-dev] Gitting rid of "(inconsistently failed then succeeded)" ?
by Laura Creighton April 28, 2009

April 28, 2009

In a message of Tue, 28 Apr 2009 12:14:54 +0200, holger krekel writes: >i agree, the error message is slightly mysterious. what about this: > > def test_inconsistent(): > def f(l=[1,0]): > return l.pop() >> assert f() >E AssertionError: (assert failed but re-evaluating the >assert expression for printing intermediate values lead to a >True value. advise: avoid side-effects in assert expressions >or use --nomagic) > >It's a bit longish but i doubt people encountering the problem >would know where to lookup things in the documentation. >Any other suggestion for the error message? > >cheers, > >holger I think that if you are going to be that long, then you might as well be a bit longer. I also think that the word you were looking for was 'advice', which rhymes with mice, and is a noun, and not 'advise' which rhymes with 'surprise' and is a verb, which means to give somebody advice. I like 'suggest' better, but maybe that is just me. When I've run into this before it is in the context of doing TDD with children. They don't know what a side effect is, and I don't think that your error message explains that there is a real problem with the way that they wrote the assert in the first place. At any rate, the puzzling thing around here was that it passed in the second case, not that it failed the first time around, but it left students with the idea that maybe their code was correct, when it wasn't. I also think that it is more natural to talk about asserts failing and then passing, or being false and then true, rather than failing and then becoming true. So here's my attempt at an error message: E: AssertionError: Evaluating the assert has undesirable side-effects. The assert fails when the test is first run, but when subsequently re-evaluated for printing intermediate values, it passes. Suggest: rewriting the assert expression in a way that avoids side-effects, or use --nomagic) Laura

2 1

[py-dev] Gitting rid of "(inconsistently failed then succeeded)" ?
by Philippe Fremy April 28, 2009

April 28, 2009

Hi, I am getting "(inconsistently failed then succeeded)" which are quite annoying. It's for code that checks conditions maniuplated by threads: t = threading.Thread( target=checker.start, args=(elcConfig, result) ) t.start() time.sleep( 0.1 ) checker.stop( False ) if not t.isAlive(): assert False if checker.isFinished(): assert False checker.join() > if t.isAlive(): assert False E AssertionError: (inconsistently failed then succeeded) I am playing a bit with race conditions here, but should that be a reason for my test to fail ? The conditions that I am checking arrive in the right order, only py.test is complaining. Any way I can get rid of "(inconsistently failed then succeeded)" ? cheers, Philippe

4 5

[py-dev] Logging over execnet?
by William McVey April 27, 2009

April 27, 2009

I'm using py.execnet with the SshGateway and I'd like to fire off logging messages that get sent over the ssh connection. I was wondering if someone has already coded up a logging handler for this. Otherwise, I'm looking for suggestions on how to get logging messages sent from the remote side back to the local side. My goal would be that the logging events get sent over the ssh connection and get injected to the logging handler of the local/client side of the ssh connection. Also, is there is a "zero footprint" way of distributing the py library (specifically, the py.path component) to the remote side of a py.execnet? -- William P.S. I'd prefer the logging solution to use the standard library logging package, but if py.log makes exchanging messages over an execnet particularly easy, that would be fine by me as well.

3 3

[py-dev] Keyboard interrupt causes unclean shutdown in py.test & py.execnet
by Simon April 20, 2009

April 20, 2009

Hi all, In my test harness, I often need to run the test code against a server. To do this I kick off a process on another machine (from the test scripts) to open up network connections. This remote process is run using py.execnet. What I find is that if the tests run to completion, everything is okay. However if I Control-C the test harness halfway through, the remote machine is left with an orphaned process: python -u -c exec input() It looks like the sshd instance has been killed but the python process is still alive. What is the correct way to shutdown an execnet connection so that there a no orphans left behind? Also what is a good way to hook this into the py.test infrastructure.? Simon

1 0

[py-dev] blog post on py.test beta and new docs
by holger krekel April 18, 2009

April 18, 2009

Hi all, just published a new post with tons of links into some new documentation. Plugins and extensions still need better documentation and refinements but i hope you like it already. The blog post also talks about the imminent move to mercurial and other niceties. http://tinyurl.com/cdgfj2 cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

1 0

[py-dev] py-trunk on bitbucket / mercurial
by holger krekel April 12, 2009

April 12, 2009

Hi everybody, since yesterday i am experimenting with using mercurial for py lib development. I have mirrored svn/py/trunk via "hgsvn" here: http://bitbucket.org/hpk42/py-trunk/ and work from there currently. You can follow the project there, fork off your own branches and also submit issues. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

1 0