<br><div class="gmail_extra"><div class="gmail_quote">On Sun, Dec 9, 2012 at 10:06 PM, Alex Gaynor <span dir="ltr"><<a href="mailto:alex.gaynor@gmail.com" target="_blank">alex.gaynor@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Title pretty much says it all, I've got some code that execs, I want to write tests for it. So far I'm just having my tests fork, which sucks but works ok. I've also thought about mocking exec, but that seems brittle (although maybe not, exec is kind of a well defined API boundary. I'm wondering if anyone has any suggestions?</blockquote>
<div><br></div><div>os.execv*() is well defined so don't feel bad if stubbing it out is what you choose to do for simplicity.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br></div><div>Alex</div><div><br></div><div>PS: Motivation for moving away from fork is that py.test --looponfail leaks child processes, and I'm getting tired of cleaning up zombies every 5 minutes :D</div></blockquote>
<div><br></div><div>Running the code being tested within a subprocess one way or another is the way to test that exec actually did what you asked it to... I'd also avoid fork() itself within your test code but there is no reason you can't use subprocess to launch a small stand alone program as your test case that the parent monitors one way or another to figure out if it did the right thing.</div>
<div><br></div><div>Several subprocess tests in the standard library do this.</div><div><br></div><div>-gps</div><div><br></div><div>PS as always if you're doing this in Python 2.x i recommend using subprocess32.</div>
</div></div>