============================================
Summer of PyPy proposal: Distributed py.test
============================================


Purpose:
========

The main purpose of distributing py.test is to speedup tests
of actual applications (running all pypy tests already takes
ages).

Method:
=======

Remote imports:
---------------

On the beggining of communication, master server sends to client
import hook code, which then can import all needed libraries.

Libraries are uploaded server -> client if they're needed (when
__import__ is called). Possible extension is to add some kind of
checksum (md5?) and store files in some directory.

Previous experiments:
---------------------

Previous experiments tried to run on the lowest level - when function/
method is called. This is pretty clear (you run as few code on client
side as possible), but has got some drawbacks:

- You must simulate *everything* and transform it to server side in
  case of need of absolutely anything (tracebacks, short and long,
  source code etc.)
- It's sometimes hard to catch exceptions.
- Top level code in testing module does not work at all.

Possible approach:
------------------

On client side (side really running tests) run some kind of cut-down
session, which is imported by remote import at the very beginning and
after that, we run desired tests (probably by importing whole test
file which allows us to have top-level imports).

Then we transfer output data to server as string, possibly tweaking
file names (which is quite easy).

Delivarables:
=============

- better use of testing machines
- cut down test time
- possible extension to run distributed code testing, by running and
  controlling several distributed parts on different machines.
