Ramblings

March 14, 2008

Testing your website… not the controllers or internal functions but the website’s output

Filed under: dev, python — michaelangela @ 2:16 am

This is quite interesting.

Advogato: Introduction: Testing Python Web applications using twill and wsgi_intercept

One of the thorniest problems in GUI application development is how to test your user interface. Web applications, as a specific and somewhat limited example of a GUI, are no exception to this problem. However, there are several options for testing Web applications now available. One of my favorites is twill, a remote HTTP driver application that lets you script Web sites. (Disclaimer: I am the primary author of twill, so take my recommendation with a grain of salt ;).

…snip…

Using twill for unit tests brings in a new problem, however: the setup
and teardown of the Web site. This is true not just for twill but for
any other HTTP driver, such as urllib2, webtest,
webunit, mechanize, mechanoid, and zope.testbrowser:
you still have to set up your development Web site to serve pages,
so that it looks and behaves like your real site. In practice, this
breaks down into multiple sub-problems:

  • you have to start
    another process; that process has to bind to a port and a hostname
    (usually something like localhost:8080);
  • your unit tests have to
    wait for the Web site to start up, which can take a second or two;

  • and then you have to shut the Web site down at the end of the
    unit tests.

…snip snip…

Well, after a a
suggestion
from Ian Bicking, I implemented an in-process
test harness for WSGI applications, called wsgi_intercept.
Briefly, wsgi_intercept lets you mount any WSGI-compliant Web
application as a fake remote server. Calls to this server from enabled
HTTP drivers are intercepted and fed directly into the WSGI application.
This means that as long as the Web framework you’re using supports WSGI
— and most of them do — you can test your application without going
through forking a new process, binding a socket, or actually exposing
the application to external input. But, because wsgi_intercept acts at
the level of httplib, your application looks and behaves like it does
when it is actually bound to a socket.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: