Yes, exactly, I want to do both (in-process and subprocess). So while I'm hacking on the new features I'd run in-process for speed and then I'd use something like tox to run proper subprocess tests in different environments. And those would be the same tests, I'd just change some configuration setting to switch between the two approaches.
And there are indeed limitations to the in-process approach, like the one you described, so perhaps it would be useful to be able to override the config setting in particular tests that don't work with it. On Thu, Apr 28, 2016 at 3:33 PM Ionel Cristian Mărieș <[email protected]> wrote: > > On Thu, Apr 28, 2016 at 4:21 PM, Vasily Kuznetsov <[email protected]> > wrote: > >> >> pytest-cram and cram in general looks quite neat, but I guess it doesn't >> allow the second approach of running everything in the same python process, >> which is an important feature for example for doing TDD. >> > > That reminds me of that time I decided to do in-process testing, cause > TDD and I had just a bunch of functions around, nothing special right? Too > bad I forgot the console app used os.execv inside. Looked mystified for a > while at why pytest suddenly exits. Can't say how long - a bit too > embarrassing. > > The point I'm trying to make is that subprocess tests (in the same vein > as integration tests) are the way to go if you want to ensure the users are > going to get exactly same behavior you get in the test suite. > > > > Thanks, > -- Ionel Cristian Mărieș, http://blog.ionelmc.ro >
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
