[svn r38743] fix and remove unneeded external references
remote test-distributed.txt which had lots of not actual links and IMO would need a higher-level introduction to become understandable. --HG-- branch : trunk
This commit is contained in:
parent
e4d4fb7c56
commit
18120135a3
|
@ -282,7 +282,3 @@ Questions, remarks, etc.
|
|||
|
||||
For more information, questions, remarks, etc. see http://codespeak.net/py.
|
||||
This website also contains links to mailing list and IRC channel.
|
||||
|
||||
.. _`initpkg`: http://codespeak.net/svn/py/dist/py/initpkg.py
|
||||
.. _`py.test documentation`: http://codespeak.net/svn/py/dist/py/documentation/test.txt
|
||||
|
||||
|
|
|
@ -22,13 +22,12 @@ useful on their own as a way to make advanced control flow structures.
|
|||
For example, we can recreate generators; the difference with Python's own
|
||||
generators is that our generators can call nested functions and the nested
|
||||
functions can yield values too. (Additionally, you don't need a "yield"
|
||||
keyword. See the example in `test_generator.py`_).
|
||||
keyword. See the example in :source:`py/c-extension/greenlet/test_generator.py`).
|
||||
|
||||
Greenlets are provided as a C extension module for the regular unmodified
|
||||
interpreter.
|
||||
|
||||
.. _`Stackless`: http://www.stackless.com
|
||||
.. _`test_generator.py`: http://codespeak.net/svn/user/arigo/greenlet/test_generator.py
|
||||
|
||||
Example
|
||||
-------
|
||||
|
|
|
@ -1,71 +0,0 @@
|
|||
=======================================================
|
||||
The ``py.test`` distributed features - developer's view
|
||||
=======================================================
|
||||
|
||||
.. contents::
|
||||
.. sectnum::
|
||||
|
||||
starting point: new session objects
|
||||
===================================
|
||||
|
||||
There are two new session objects, both located in `rsession.py`_. `RSession`
|
||||
and `LSession`. `RSession` is responsible for running tests distributedly,
|
||||
while `LSession` runs tests locally, but with different implementation
|
||||
details (as well as using details).
|
||||
|
||||
Abstraction layers:
|
||||
===================
|
||||
|
||||
Main difference between normal session and `(L|R)Session` is split into
|
||||
reporter and actual session. Reporter is an object or function (also defined
|
||||
in `rsession.py`_) which gets all the events (listed in `report.py`_) and
|
||||
represents them to the user. Default reporter is command line one (to be
|
||||
precise, there are different reporters for L and R Sessions because of
|
||||
different needs), but there is existing reporter which runs web server
|
||||
(`web.py`_) and communicates over XMLHttp requests with the browser.
|
||||
|
||||
Writing down new reporter is relatively easy, way easier than writing session
|
||||
from a scratch, so one can write down GTK reporter and whatnot.
|
||||
|
||||
Only thing to do is to write down new reporter classs which subclasses
|
||||
`AbstractReporter` in `reporter.py`_ and overrides all the report_Xxx methods
|
||||
(each of these method is called when one of the message, defined in
|
||||
`report.py`_ arrives to reporter). Special consideration is needed when dealing
|
||||
with ReceivedItemOutcome, which is in details described in `outcome.py`_.
|
||||
|
||||
Another abstraction layer (present only in `LSession`) is runner. Actual
|
||||
object which runs tests. There are two existing runners: box_runner and
|
||||
plain_runner, both defined in `local.py`_. box_runner can run tests
|
||||
after fork, so signals are properly handled (you get error instead of
|
||||
crash of all the program), plain_runner is running in local process, needed
|
||||
for --pdb command line option for example. There are several different runners
|
||||
in my mind, like exec_runner (for implementing --exec), apigen_runner, for
|
||||
creating documentation, benchamrk_runner for benchmarks etc. etc.
|
||||
|
||||
.. _`rsession.py`: http://codespeak.net/svn/py/dist/py/test/rsession/rsession.py
|
||||
.. _`report.py`: http://codespeak.net/svn/py/dist/py/test/rsession/report.py
|
||||
.. _`web.py`: http://codespeak.net/svn/py/dist/py/test/rsession/web.py
|
||||
.. _`local.py`: http://codespeak.net/svn/py/dist/py/test/rsession/local.py
|
||||
.. _`reporter.py`: http://codespeak.net/svn/py/dist/py/test/rsession/reporter.py
|
||||
.. _`outcome.py`: http://codespeak.net/svn/py/dist/py/test/rsession/outcome.py
|
||||
|
||||
Implemented features:
|
||||
=====================
|
||||
|
||||
Actually most of normal py.test features are implemented in distributed
|
||||
version. Quite missing is testing LSession under
|
||||
OSX/Windows or other machines than mine.
|
||||
|
||||
Unique features:
|
||||
================
|
||||
|
||||
Besides distribution (which is quite unique for testing framework I guess)
|
||||
there is boxing code (`box.py`_) which makes possible catching SIGSEGV and
|
||||
other strange stuff as well as separates memory usage between tests (ie
|
||||
we're quite sure that memory is not kept allocated during test runs) as long
|
||||
as it's not gathered during setup/teardown stuff.
|
||||
|
||||
Another unique feature is web server which allows you to track down tests and
|
||||
how they goes.
|
||||
|
||||
.. _`box.py`: http://codespeak.net/svn/py/dist/py/test/rsession/box.py
|
Loading…
Reference in New Issue