[pytest-dev] py.test foreground service listener

[holger krekel]

On Wed, Mar 06, 2013 at 10:04 -0500, Alfredo Deza wrote:
> I was looking into passing a path (which can contain some options as well)
> to a foreground py.test process that is "listening" for commands to run.
> 
> This would help integrate text editors easily send a non-blocking test to
> the terminal so that further interaction can take place there. Complex
> tests that take very long  (or need debugging via pdb) can be very
> problematic to run from an editor.
> 
> Most editors don't have a terminal emulator, so it is either cumbersome or
> impossible to jump from the editor to the shell. Having a foreground
> py.test process would help here.
> 
> The context would look similar to this:
> 
>     $ py.test --foreground --listen=/some/socket
>     ============= foreground process starts =============
>     platform darwin -- Python 2.7.2 -- pytest-2.3.4
>     listening on: /some/socket
> 
> And then from an editor some utility would send the desired path with
> options:
> 
>     utility '-s /path/to/test_file.py' --socket=/some/socket
> 
> The listener would then receive the above command and execute:
> 
>     received test task
>     collected 1 item
> 
>     /path/to/test_file.py .
>     ========== 1 passed in 0.01 seconds ==========
> 
> And then it would again keep listening for more "tasks". The scenario above
> is very simple, but as things get complicated, with more options (like
> dropping to pdb) it gets more useful.
> 
> On IRC Ronny mentioned that this would be very tricky to accomplish
> (probably issues with the import cache). So this would mean that currently,
> a plugin would just not be suitable?

As ronny already hints at, i think the listening foreground process 
would receive test paths to run along with options, but it would not 
even import "pytest" or any of the test files itself.  Instead it invokes
a "py.test [options] testpaths" subprocess (passing through 
stdin/stdout/stderr) and passing back return values.

Such a listener process could be rather simple and probably shouldn't
be a plugin (after all we don't even want to "import pytest" in it).
It should rather be a "pytest-wrapserver" script and i assume it would
be a rather simple thing to do, no changes to pytest required.

Unless i am missing something, of course :)

holger


> 
> Are there any options that would be left for such a thing? If not coming
> directly out of py.test maybe a wrapper would probably work here but I am
> not aware of any tool that may help.
> 
> Any ideas/feedback would be great.
> 
> 
> -Alfredo

> _______________________________________________
> Pytest-dev mailing list
> Pytest-dev at python.org
> http://mail.python.org/mailman/listinfo/pytest-dev