[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. | For more information, questions, remarks, etc. see http://codespeak.net/py. | ||||||
| This website also contains links to mailing list and IRC channel. | 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 | For example, we can recreate generators; the difference with Python's own | ||||||
| generators is that our generators can call nested functions and the nested | generators is that our generators can call nested functions and the nested | ||||||
| functions can yield values too.  (Additionally, you don't need a "yield" | 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 | Greenlets are provided as a C extension module for the regular unmodified | ||||||
| interpreter. | interpreter. | ||||||
| 
 | 
 | ||||||
| .. _`Stackless`: http://www.stackless.com | .. _`Stackless`: http://www.stackless.com | ||||||
| .. _`test_generator.py`: http://codespeak.net/svn/user/arigo/greenlet/test_generator.py |  | ||||||
| 
 | 
 | ||||||
| Example | 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