<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 10, 2013 at 6:31 PM, Jeroen van Meeuwen (Kolab Systems) <span dir="ltr"><<a href="mailto:vanmeeuwen@kolabsys.com" target="_blank">vanmeeuwen@kolabsys.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span style="color:rgb(34,34,34)">ave no objections, but could you show me before we change all of what we have already? ;-)</span></blockquote>
</div></blockquote><div><br></div><div>Cool :) Hold off on any new ones.</div><div>I'll try to port some existing ones to py.test</div><div>and you'll see how much simpler it is :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Question on the side... does py.test keep stdin/stdout/stderr open? I've been trying to get std. unittest to do this for me, so that I can do:<br>
<br>
  0) Clean out environment completely,<br>
<br>
  1) Set the environment up for a functional test of application $x,<br>
<br>
  2) Display the steps to reproduce and ask the Quality Assurance engineer for confirmation,<br>
<br>
  3) Handle the ACK / NAY response.</blockquote><div><br></div><div>Yes yes yes and yes. py.test has lots of cool stuff :)</div><div><br></div><div>I'll try to borrow from my vast experience with circuits's unit tests and system tests :)</div>

<div><br></div><div>cheers</div><div>James </div></div></div></div>