[pytest-dev] py.test foreground service listener

[Ronny Pfannschmidt]

Hello Alfredo,

on closer inspection the following scheme may fit,
it is semilar to the current looponfail mode but more simple to handle 
(i.e. without execnet)

instead of running an actual pytest session you can hook into 
pytest_main, and have a process that just reads lines of json from the 
socket, then passes those as args to a subprocess call to py.test

this also seems like an interesting mode of operation for tox (for posargs)

-- Ronny

On 03/06/2013 04:04 PM, 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?
>
> 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