test-standard.html [plain text]
<?xml version="1.0"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" lang="en"><head><title>Twisted Documentation: Unit Tests in Twisted</title><link href="../howto/stylesheet.css" type="text/css" rel="stylesheet" /></head><body bgcolor="white"><h1 class="title">Unit Tests in Twisted</h1><div class="toc"><ol><li><a href="#auto0">Unit Tests in the Twisted Philosophy</a></li><li><a href="#auto1">What to Test, What Not to Test</a></li><li><a href="#auto2">Running the Tests</a></li><ul><li><a href="#auto3">How</a></li><li><a href="#auto4">When</a></li></ul><li><a href="#auto5">Adding a Test</a></li><li><a href="#auto6">Skipping tests, TODO items</a></li><ul><li><a href="#auto7">.todo and Testing New Functionality </a></li></ul><li><a href="#auto8">Associating Test Cases With Source Files</a></li><li><a href="#auto9">Twisted-specific quirks: reactor, Deferreds, callLater</a></li><ul><li><a href="#auto10">Leave the Reactor as you found it</a></li><li><a href="#auto11">deferredResult</a></li><li><a href="#auto12">Waiting for Things</a></li><li><a href="#auto13">Using Timers to Detect Failing Tests</a></li></ul><li><a href="#auto14">Links</a></li></ol></div><div class="content"><span></span><p>Each <em>unit test</em> tests one bit of functionality in the
software. Unit tests are entirely automated and complete quickly.
Unit tests for the entire system are gathered into one test suite,
and may all be run in a single batch. The result of a unit test
is simple: either it passes, or it doesn't. All this means you
can test the entire system at any time without inconvenience, and
quickly see what passes and what fails.</p><h2>Unit Tests in the Twisted Philosophy<a name="auto0"></a></h2><p>The Twisted development team
adheres to the practice of <a href="http://c2.com/cgi/wiki?ExtremeProgramming">Extreme
Programming</a> (XP), and the usage of unit tests is a cornerstone
XP practice. Unit tests are a tool to give you increased
confidence. You changed an algorithm -- did you break something?
Run the unit tests. If a test fails, you know where to look,
because each test covers only a small amount of code, and you know
it has something to do with the changes you just made. If all the
tests pass, you're good to go, and you don't need to second-guess
yourself or worry that you just accidently broke someone else's
program.</p><h2>What to Test, What Not to Test<a name="auto1"></a></h2><blockquote><p>You don't have to write a test for every single
method you write, only production methods that could possibly break.</p></blockquote><p>-- Kent Beck, <cite>Extreme Programming Explained</cite>, p. 58.</p><h2>Running the Tests<a name="auto2"></a></h2><h3>How<a name="auto3"></a></h3><pre class="shell">
$ Twisted/admin/runtests
</pre><p>You'll find that having something like this in your emacs init
files is quite handy:</p><pre class="elisp">
(defun runtests () (interactive)
(compile "python /somepath/Twisted/admin/runtests"))
(global-set-key [(alt t)] 'runtests)
</pre><h3>When<a name="auto4"></a></h3><p>Always always <em>always</em> be sure <a href="http://www.xprogramming.com/xpmag/expUnitTestsAt100.htm">all the
tests pass</a> before committing any code. If someone else
checks out code at the start of a development session and finds
failing tests, they will not be happy and may decide to <em>hunt
you down</em>.</p><p>Since this is a geographically dispersed team, the person who
can help you get your code working probably isn't in the room with
you. You may want to share your work in progress over the
network, but you want to leave the main CVS tree in good working
order. So <a href="http://www.cvshome.org/docs/manual/cvs_5.html">use a branch</a>,
and merge your changes back in only after your problem is solved
and all the unit tests pass again.</p><h2>Adding a Test<a name="auto5"></a></h2><p>Please don't add new modules to Twisted without adding tests
for them too. Otherwise we could change something which breaks
your module and not find out until later, making it hard to know
exactly what the change that broke it was, or until after a
release, and nobody wants broken code in a release.</p><p>Tests go in Twisted/twisted/test/, and are named <code>test_foo.py</code>,
where <code>foo</code> is the name of the module or package being tested.
Extensive documentation on using the PyUnit framework for writing
unit tests can be found in the <a href="#links">links
section</a> below.</p><p>One deviation from the standard PyUnit documentation: To ensure
that any variations in test results are due to variations in the
code or environment and not the test process itself, Twisted ships
with its own, compatible, testing framework. That just
means that when you import the unittest module, you will <code class="python">from twisted.trial import unittest</code> instead of the
standard <code class="python">import unittest</code>.</p><p>As long as you have followed the module naming and placement
conventions, <code class="shell">runtests</code> will be smart
enough to pick up any new tests you write.</p><h2>Skipping tests, TODO items<a name="auto6"></a></h2><p>Trial, the Twisted unit test framework, has some extensions which are
designed to encourage developers to add new tests. One common situation is
that a test exercises some optional functionality: maybe it depends upon
certain external libraries being available, maybe it only works on certain
operating systems. The important common factor is that nobody considers
these limitations to be a bug.</p><p>To make it easy to test as much as possible, some tests may be skipped in
certain situations. Individual test cases can raise the
<code>SkipTest</code> exception to indicate that they should be skipped, and
the remainder of the test is not run. In the summary (the very last thing
printed, at the bottom of the test output) the test is counted as a
<q>skip</q> instead of a <q>success</q> or <q>fail</q>. This should be used
inside a conditional which looks for the necessary prerequisites:</p><pre class="python">
<span class="py-src-keyword">def</span> <span class="py-src-identifier">testSSHClient</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-keyword">if</span> <span class="py-src-keyword">not</span> <span class="py-src-variable">ssh_path</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-keyword">raise</span> <span class="py-src-variable">unittest</span><span class="py-src-op">.</span><span class="py-src-variable">SkipTest</span><span class="py-src-op">,</span> <span class="py-src-string">"cannot find ssh, nothing to test"</span><span class="py-src-newline">
</span> <span class="py-src-dedent"></span><span class="py-src-variable">foo</span><span class="py-src-op">(</span><span class="py-src-op">)</span> <span class="py-src-comment"># do actual test after the SkipTest</span><span class="py-src-newline">
</span><span class="py-src-dedent"></span><span class="py-src-endmarker"></span></pre><p>You can also set the .skip attribute on the method, with a string to
indicate why the test is being skipped. This is convenient for temporarily
turning off a test case, but it can also be set conditionally (by
manipulating the class attributes after they've been defined):</p><pre class="python">
<span class="py-src-keyword">def</span> <span class="py-src-identifier">testThing</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">dotest</span><span class="py-src-op">(</span><span class="py-src-op">)</span><span class="py-src-newline">
</span><span class="py-src-dedent"></span><span class="py-src-variable">testThing</span><span class="py-src-op">.</span><span class="py-src-variable">skip</span> <span class="py-src-op">=</span> <span class="py-src-string">"disabled locally"</span><span class="py-src-newline">
</span><span class="py-src-endmarker"></span></pre><pre class="python">
<span class="py-src-keyword">class</span> <span class="py-src-identifier">MyTestCase</span><span class="py-src-op">(</span><span class="py-src-parameter">unittest</span><span class="py-src-op">.</span><span class="py-src-parameter">TestCase</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-keyword">def</span> <span class="py-src-identifier">testOne</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-op">.</span><span class="py-src-op">.</span><span class="py-src-op">.</span><span class="py-src-newline">
</span> <span class="py-src-dedent"></span><span class="py-src-keyword">def</span> <span class="py-src-identifier">testThing</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">dotest</span><span class="py-src-op">(</span><span class="py-src-op">)</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span><span class="py-src-dedent"></span><span class="py-src-dedent"></span><span class="py-src-keyword">if</span> <span class="py-src-keyword">not</span> <span class="py-src-variable">haveThing</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">MyTestCase</span><span class="py-src-op">.</span><span class="py-src-variable">testThing</span><span class="py-src-op">.</span><span class="py-src-variable">im_func</span><span class="py-src-op">.</span><span class="py-src-variable">skip</span> <span class="py-src-op">=</span> <span class="py-src-string">"cannot test without Thing"</span><span class="py-src-newline">
</span> <span class="py-src-comment"># but testOne() will still run
</span><span class="py-src-dedent"></span><span class="py-src-endmarker"></span></pre><p>Finally, you can turn off an entire TestCase at once by setting the .skip
attribute on the class. If you organize your tests by the functionality they
depend upon, this is a convenient way to disable just the tests which cannot
be run.</p><pre class="python">
<span class="py-src-keyword">class</span> <span class="py-src-identifier">SSLTestCase</span><span class="py-src-op">(</span><span class="py-src-parameter">unittest</span><span class="py-src-op">.</span><span class="py-src-parameter">TestCase</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-op">.</span><span class="py-src-op">.</span><span class="py-src-op">.</span><span class="py-src-newline">
</span><span class="py-src-dedent"></span><span class="py-src-keyword">class</span> <span class="py-src-identifier">TCPTestCase</span><span class="py-src-op">(</span><span class="py-src-parameter">unittest</span><span class="py-src-op">.</span><span class="py-src-parameter">TestCase</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-op">.</span><span class="py-src-op">.</span><span class="py-src-op">.</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span><span class="py-src-dedent"></span><span class="py-src-keyword">if</span> <span class="py-src-keyword">not</span> <span class="py-src-variable">haveSSL</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">SSLTestCase</span><span class="py-src-op">.</span><span class="py-src-variable">skip</span> <span class="py-src-op">=</span> <span class="py-src-string">"cannot test without SSL support"</span><span class="py-src-newline">
</span> <span class="py-src-comment"># but TCPTestCase will still run
</span><span class="py-src-dedent"></span><span class="py-src-endmarker"></span></pre><h3>.todo and Testing New Functionality <a name="auto7"></a></h3><p>Two good practices which arise from the <q>XP</q> development process are
sometimes at odds with each other:</p><ul><li>Unit tests are a good thing. Good developers recoil in horror when
they see a failing unit test. They should drop everything until the test
has been fixed.</li><li>Good developers write the unit tests first. Once tests are done, they
write implementation code until the unit tests pass. Then they stop.</li></ul><p>These two goals will sometimes conflict. The unit tests that are written
first, before any implementation has been done, are certain to fail. We want
developers to commit their code frequently, for reliability and to improve
coordination between multiple people working on the same problem together.
While the code is being written, other developers (those not involved in the
new feature) should not have to pay attention to failures in the new code.
We should not dilute our well-indoctrinated Failing Test Horror Syndrome by
crying wolf when an incomplete module has not yet started passing its unit
tests. To do so would either teach the module author to put off writing or
committing their unit tests until <em>after</em> all the functionality is
working, or it would teach the other developers to ignore failing test
cases. Both are bad things.</p><p><q>.todo</q> is intended to solve this problem. When a developer first
starts writing the unit tests for functionality that has not yet been
implemented, they can set the <code>.todo</code> attribute on the test
methods that are expected to fail. These methods will still be run, but
their failure will not be counted the same as normal failures: they will go
into an <q>expected failures</q> category. Developers should learn to treat
this category as a second-priority queue, behind actual test failures.</p><p>As the developer implements the feature, the tests will eventually start
passing. This is surprising: after all those tests are marked as being
expected to fail. The .todo tests which nevertheless pass are put into a
<q>unexpected success</q> category. The developer should remove the .todo
tag from these tests. At that point, they become normal tests, and their
failure is once again cause for immediate action by the entire development
team.</p><p>The life cycle of a test is thus:</p><ol><li>Test is created, marked <code>.todo</code>. Test fails: <q>expected
failure</q>.</li><li>Code is written, test starts to pass. <q>unexpected success</q>.</li><li><code>.todo</code> tag is removed. Test passes. <q>success</q>.</li><li>Code is broken, test starts to fail. <q>failure</q>. Developers spring
into action.</li><li>Code is fixed, test passes once more. <q>success</q>.</li></ol><p>Any test which remains marked with <code>.todo</code> for too long should
be examined. Either it represents functionality which nobody is working on,
or the test is broken in some fashion and needs to be fixed.</p><h2>Associating Test Cases With Source Files<a name="auto8"></a></h2><p>Please add a <code>test-case-name</code> tag to the source file that is
covered by your new test. This is a comment at the beginning of the file
which looks like one of the following:</p><pre class="python">
<span class="py-src-comment"># -*- test-case-name: twisted.test.test_defer -*-
</span><span class="py-src-endmarker"></span></pre><p>or</p><pre class="python">
<span class="py-src-comment">#!/usr/bin/python
</span><span class="py-src-comment"># -*- test-case-name: twisted.test.test_defer -*-
</span><span class="py-src-endmarker"></span></pre><p>This format is understood by emacs to mark <q>File Variables</q>. The
intention is to accept <code>test-case-name</code> anywhere emacs would on
the first or second line of the file (but not in the <code>File
Variables:</code> block that emacs accepts at the end of the file). If you
need to define other emacs file variables, you can either put them in the
<code>File Variables:</code> block or use a semicolon-separated list of
variable definitions:</p><pre class="python">
<span class="py-src-comment"># -*- test-case-name: twisted.test.test_defer; fill-column: 75; -*-
</span><span class="py-src-endmarker"></span></pre><p>If the code is exercised by multiple test cases, those may be marked by
using a comma-separated list of tests, as follows: (NOTE: not all tools can
handle this yet.. trial --testmodule does, though)</p><pre class="python">
<span class="py-src-comment"># -*- test-case-name: twisted.test.test_defer,twisted.test.test_tcp -*-
</span><span class="py-src-endmarker"></span></pre><p>The <code>test-case-name</code> tag will allow <code class="shell">trial
--testmodule twisted/dir/myfile.py</code> to determine which test cases need
to be run to exercise the code in <code>myfile.py</code>. Several tools (as
well as <code>twisted-dev.el</code>'s F9 command) use this to automatically
run the right tests.</p><h2>Twisted-specific quirks: reactor, Deferreds, callLater<a name="auto9"></a></h2><p>The standard Python <code>unittest</code> framework, from which Trial is
derived, is ideal for testing code with a fairly linear flow of control.
Twisted is an asynchronous networking framework which provides a clean,
sensible way to establish functions that are run in response to events (like
timers and incoming data), which creates a highly non-linear flow of control.
Trial has a few extensions which help to test this kind of code. This section
provides some hints on how to use these extensions and how to best structure
your tests.</p><h3>Leave the Reactor as you found it<a name="auto10"></a></h3><p>Trial runs the entire test suite (over one thousand tests) in a single
process, with a single reactor. Therefore it is important that your test
leave the reactor in the same state as it found it. Leftover timers may
expire during somebody else's unsuspecting test. Leftover connection attempts
may complete (and fail) during a later test. These lead to intermittent
failures that wander from test to test and are very time-consuming to track
down.</p><p>Your test is responsible for cleaning up after itself. The
<code>tearDown</code> method is an ideal place for this cleanup code: it is
always run regardless of whether your test passes or fails (like a bare
<code>except</code> clause in a try-except construct). Exceptions in tearDown
are flagged as errors and flunk the test.</p><p>TODO: helper functions: TestCase.addPort, TestCase.addTimer</p><p>reactor.stop is considered very harmful, and should only be used by
reactor-specific test cases which know how to restore the state that it
kills. If you must use reactor.run, use reactor.crash to stop it instead of
reactor.stop.</p><p>Trial tries to help insure that the reactor is clean after each test, but
the reactor does not yet support an interface that would make this work
properly. It can catch leftover timers, but not lingering sockets.</p><h3>deferredResult<a name="auto11"></a></h3><p>If your test creates a <code class="API"><a href="http://twistedmatrix.com/documents/TwistedDocs/TwistedDocs-1.3.0/api/twisted.internet.defer.Deferred.html" title="twisted.internet.defer.Deferred">Deferred</a></code> and simply wants to verify
something about its result, use <code class="API"><a href="http://twistedmatrix.com/documents/TwistedDocs/TwistedDocs-1.3.0/api/twisted.trial.util.deferredResult.html" title="twisted.trial.util.deferredResult">deferredResult</a></code>. It will wait for the
Deferred to fire and give you the result. If the Deferred runs the errback
handler instead, it will raise an exception so your test can fail. Note that
the <em>only</em> thing that will terminate a <code>deferredResult</code>
call is if the Deferred fires; in particular, timers which raise exceptions
will not cause it to return.</p><h3>Waiting for Things<a name="auto12"></a></h3><p>The preferred way to run a test that waits for something to happen (always
triggered by other things that you have done) is to use a <code class="python">while not self.done</code> loop that does <code class="python">reactor.iterate(0.1)</code> at the beginning of each pass. The
<q>0.1</q> argument sets a limit on how long the reactor will wait to return
if there is nothing to do. 100 milliseconds is long enough to avoid spamming
the CPU while your timers wait to expire.</p><h3>Using Timers to Detect Failing Tests<a name="auto13"></a></h3><p>It is common for tests to establish some kind of fail-safe timeout that
will terminate the test in case something unexpected has happened and none of
the normal test-failure paths are followed. This timeout puts an upper bound
on the time that a test can consume, and prevents the entire test suite from
stalling because of a single test. This is especially important for the
Twisted test suite, because it is run automatically by the buildbot whenever
changes are committed to the CVS repository.</p><p>Trial tests indicate they have failed by raising a FailTest exception
(self.fail and friends are just wrappers around this <code class="python">raise</code> statement). Exceptions that are raised inside a
callRemote timer are caught and logged but otherwise ignored. Trial uses a
logging hook to notice when errors have been logged by the test that just
completed (so such errors will flunk the test), but this happens after the
fact: they will not be noticed by the main body of your test code. Therefore
callRemote timers can not be used directly to establish timeouts which
terminate and flunk the test.</p><p>The right way to implement this sort of timeout is to have a
<code>self.done</code> flag, and a while loop which iterates the reactor
until it becomes true. Anything that causes the test to be finished (success
<em>or</em> failure) can set self.done to cause the loop to exit.</p><p>Most of the code in Twisted is run by the reactor as a result of socket
activity. This is almost always started by Protocol.connectionMade or
Protocol.dataReceived (because the output side goes through a buffer which
queues data for transmission). Exceptions that are raised by code called in
this way (by the reactor, through doRead or doWrite) are caught, logged,
handed to connectionLost, and otherwise ignored.</p><p>This means that your Protocol's connectionLost method, if invoked because
of an exception, must also set this self.done flag. Otherwise the test will
not terminate.</p><p>Exceptions that are raised in a Deferred callback are turned into a
Failure and stashed inside the Deferred. When an errback handler is attached,
the Failure is given to it. If the Deferred goes out of scope while an error
is still pending, the error is logged just like exceptions that happen in
timers or protocol handlers. This will cause the current test to flunk
(eventually), but it is not checked until after the test fails. So again, it
is a good idea to add errbacks to your Deferreds that will terminate your
test's main loop.</p><p>Here is a brief example that demonstrates a few of these techniques.</p><pre class="python">
<span class="py-src-keyword">class</span> <span class="py-src-identifier">MyTest</span><span class="py-src-op">(</span><span class="py-src-parameter">unittest</span><span class="py-src-op">.</span><span class="py-src-parameter">TestCase</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-keyword">def</span> <span class="py-src-identifier">setUp</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">done</span> <span class="py-src-op">=</span> <span class="py-src-variable">False</span><span class="py-src-newline">
</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">failure</span> <span class="py-src-op">=</span> <span class="py-src-variable">None</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span> <span class="py-src-dedent"></span><span class="py-src-keyword">def</span> <span class="py-src-identifier">tearDown</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">server</span><span class="py-src-op">.</span><span class="py-src-variable">stopListening</span><span class="py-src-op">(</span><span class="py-src-op">)</span><span class="py-src-newline">
</span> <span class="py-src-comment"># TODO: also shut down client
</span> <span class="py-src-keyword">try</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">timeout</span><span class="py-src-op">.</span><span class="py-src-variable">cancel</span><span class="py-src-op">(</span><span class="py-src-op">)</span><span class="py-src-newline">
</span> <span class="py-src-dedent"></span><span class="py-src-keyword">except</span> <span class="py-src-op">(</span><span class="py-src-variable">error</span><span class="py-src-op">.</span><span class="py-src-variable">AlreadyCancelled</span><span class="py-src-op">,</span> <span class="py-src-variable">error</span><span class="py-src-op">.</span><span class="py-src-variable">AlreadyCalled</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-keyword">pass</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span> <span class="py-src-dedent"></span><span class="py-src-dedent"></span><span class="py-src-keyword">def</span> <span class="py-src-identifier">succeeded</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">done</span> <span class="py-src-op">=</span> <span class="py-src-variable">True</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span> <span class="py-src-dedent"></span><span class="py-src-keyword">def</span> <span class="py-src-identifier">failed</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">,</span> <span class="py-src-parameter">why</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">done</span> <span class="py-src-op">=</span> <span class="py-src-variable">True</span><span class="py-src-newline">
</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">failure</span> <span class="py-src-op">=</span> <span class="py-src-variable">why</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span> <span class="py-src-dedent"></span><span class="py-src-keyword">def</span> <span class="py-src-identifier">testServer</span><span class="py-src-op">(</span><span class="py-src-parameter">self</span><span class="py-src-op">)</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">server</span> <span class="py-src-op">=</span> <span class="py-src-variable">reactor</span><span class="py-src-op">.</span><span class="py-src-variable">listenTCP</span><span class="py-src-op">(</span><span class="py-src-variable">port</span><span class="py-src-op">,</span> <span class="py-src-variable">factory</span><span class="py-src-op">)</span><span class="py-src-newline">
</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">client</span> <span class="py-src-op">=</span> <span class="py-src-variable">reactor</span><span class="py-src-op">.</span><span class="py-src-variable">connectTCP</span><span class="py-src-op">(</span><span class="py-src-variable">port</span><span class="py-src-op">,</span> <span class="py-src-variable">factory</span><span class="py-src-op">)</span><span class="py-src-newline">
</span> <span class="py-src-comment"># you should give the factories a way to call our 'succeeded' or
</span> <span class="py-src-comment"># 'failed' methods
</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">timeout</span> <span class="py-src-op">=</span> <span class="py-src-variable">reactor</span><span class="py-src-op">.</span><span class="py-src-variable">callLater</span><span class="py-src-op">(</span><span class="py-src-number">5</span><span class="py-src-op">,</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">failed</span><span class="py-src-op">,</span> <span class="py-src-string">"timeout"</span><span class="py-src-op">)</span><span class="py-src-newline">
</span> <span class="py-src-keyword">while</span> <span class="py-src-keyword">not</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">done</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">reactor</span><span class="py-src-op">.</span><span class="py-src-variable">iterate</span><span class="py-src-op">(</span><span class="py-src-number">0.1</span><span class="py-src-op">)</span><span class="py-src-newline">
</span><span class="py-src-nl">
</span> <span class="py-src-comment"># we get here if the test is finished, for good or for bad
</span> <span class="py-src-dedent"></span><span class="py-src-keyword">if</span> <span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">failure</span><span class="py-src-op">:</span><span class="py-src-newline">
</span><span class="py-src-indent"> </span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">fail</span><span class="py-src-op">(</span><span class="py-src-variable">self</span><span class="py-src-op">.</span><span class="py-src-variable">failure</span><span class="py-src-op">)</span><span class="py-src-newline">
</span> <span class="py-src-comment"># otherwise it probably passed. Cleanup will be done in tearDown()
</span><span class="py-src-dedent"></span><span class="py-src-dedent"></span><span class="py-src-dedent"></span><span class="py-src-endmarker"></span></pre><h2 id="links">Links<a name="auto14"></a></h2><a name="links"></a><ul><li>A chapter on <a href="http://diveintopython.org/roman_divein.html">Unit Testing</a>
in Mark Pilgrim's <a href="http://diveintopython.org">Dive Into
Python</a>.</li><li><a href="http://www.python.org/doc/current/lib/module-unittest.html"><code>unittest</code></a> module documentation, in the <a href="http://www.python.org/doc/current/lib/">Python Library
Reference</a>.</li><li><a href="http://c2.com/cgi/wiki?UnitTests">UnitTests</a> on
the <a href="http://c2.com/cgi/wiki">PortlandPatternRepository
Wiki</a>, where all the cool <a href="http://c2.com/cgi/wiki?ExtremeProgramming">ExtremeProgramming</a> kids hang out.</li><li><a href="http://www.extremeprogramming.org/rules/unittests.html">Unit
Tests</a> in <a href="http://www.extremeprogramming.org">Extreme Programming: A Gentle Introduction</a>.</li><li>Ron Jeffries espouses on the importance of <a href="http://www.xprogramming.com/xpmag/expUnitTestsAt100.htm">Unit
Tests at 100%</a>.</li><li>Ron Jeffries writes about the <a href="http://www.xprogramming.com/Practices/PracUnitTest.html">Unit
Test</a> in the <a href="http://www.xprogramming.com/Practices/xpractices.htm">Extreme
Programming practices of C3</a>.</li><li><a href="http://pyunit.sourceforge.net">PyUnit's homepage</a>.</li><li><a href="http://twistedmatrix.com/documents/TwistedDocs/current/api/public/toc-twisted.test-module.html">twisted.test</a>'s inline documentation.</li><li>The <a href="http://twistedmatrix.com/users/jh.twistd/viewcvs/cgi/viewcvs.cgi/twisted/test/?cvsroot=Twisted">twisted/test directory</a> in CVS.</li></ul></div><p><a href="../howto/index.html">Index</a></p><span class="version">Version: 1.3.0</span></body></html>