1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
============================
Testing Web sites with twill
============================
twill was initially designed for testing Web sites, although since then
people have also figured out that it's good for browsing_ unsuspecting
Web sites.
.. _browsing: browsing.html
Using twill-sh
~~~~~~~~~~~~~~
The simplest way to test Web sites is to write one or more twill scripts
and then simply run ::
twill-sh [ -u initial_url ] script(s)
either from the command-line (for development purposes), via a cron job
(to check to see if sites are up and responding), or from your functional
or unit tests (see below).
twill-sh will try to run each script given to it on the command line
once, and will report the number of scripts that failed. The exit value
of the script will be 0 if there are no failures, so you can use it in
a shell script easily enough.
twill-sh will gather scripts from directories, so you can create a whole
directory hierarchy containing your scripts and they will all be gathered
and run, in standard lexical order.
The ``-u`` flag can be used to give twill-sh an initial URL; this is
equivalent to placing a "go (initial_url)" command at the top of the
script, but is particularly handy for test frameworks where the URL
might change depending on the developer.
Stress testing
~~~~~~~~~~~~~~
You can use the `twill-fork` script to do some stress testing. The syntax is
::
twill-fork -n <number to execute> -p <number of processes> script [ scripts... ]
For example,
::
twill-fork -n 500 -p 10 test-script
will fork 10 times and run `test-script` 50 times in each process.
`twill-fork` will record the time it takes to run all of the scripts specified
on the command and print a summary at the end.
The time recorded is *not* the CPU time used. (This would lead to an
inaccurate estimate because the client code uses blocking calls to
retrieve Web pages.) Rather, the time recorded is the clock time
measured between the start and end of script execution.
Try `twill-fork -h` to get a list of other command line arguments.
Note that twill-fork still needs a lot of work...
Unit testing
~~~~~~~~~~~~
twill can be used in unit testing, and it contains
some Python support infrastructure for this purpose.
As an example, here's the code from twill's own unit test, testing the
unit-test support code::
import os
import testlib
import twill.unit
import twilltestserver
from quixote.server.simple_server import run as quixote_run
def test():
# port to run the server on
PORT=8090
# create a function to run the server
def run_server_fn():
quixote_run(twilltestserver.create_publisher, port=PORT)
# abspath to the script
script = os.path.join(testlib.testdir, 'test-unit-support.twill')
# create test_info object
test_info = twill.unit.TestInfo(script, run_server_fn, PORT)
# run tests!
twill.unit.run_test(test_info)
Here, I'm unit testing the Quixote application ``twilltestserver``, which
is run by ``quixote_run`` (a.k.a. ``quixote.server.simple_server.run``) on
port ``PORT``, using the twill script ``test-unit-support.twill``. That
script contains this code::
# starting URL is provided to it by the unit test support framework.
go ./multisubmitform
code 200
A few things to note:
* the initial URL is set based on the URL reported by ``TestInfo``,
which calculates it based on the ``PORT`` argument. (This can be overriden
by subclasses.)
* ``TestInfo`` contains code to (a) run the server function in a new
process, and (b) run the twill script against that server. It then
kills the server after script completion.
* You can also pass a 'sleep' argument to the ``TestInfo`` constructor that
specifies how many seconds to wait for the server to start before
executing the script.
Testing WSGI applications "in-process"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
twill has some built-in support for testing `WSGI
applications`_.
twill contains two functions,
`add_wsgi_intercept` and `remove_wsgi_intercept`, that allow Python
applications to redirect HTTP calls into a WSGI application
"in-process", without going via an external Internet call. This is
particularly useful for unit tests, where setting up an externally
available Web server can be inconvenient.
For example, the following code redirects all ``localhost:80`` calls to
the given WSGI app: ::
def create_app():
return wsgi_app
twill.add_wsgi_intercept('localhost', 80, create_app)
See the ``tests/test-wsgi-intercept.py`` unit test for more information.
.. _WSGI applications: http://www.python.org/peps/pep-0333.html
|
