I was just looking at Rails' functional testing. Here's their first example:

require File.dirname(__FILE__) + '/../test_helper'

# grab our HomeController because we're going to test it
require 'home_controller'

# Raise errors beyond the default web-based presentation
class HomeController; def rescue_action(e) raise e end; end

class HomeControllerTest < Test::Unit::TestCase
  def setup
    @controller = HomeController.new
    @request = ActionController::TestRequest.new
    @response = ActionController::TestResponse.new
  end

  # let's test our main index page
  def test_index
    get :index
    assert_response :success
  end
end

Here's how you'd do it in Paste:

from paste.tests.fixture import *

def test_index():
    res = app.get('/')

(Note: 100% framework neutral!)

Why is it so much shorter? Well, first it uses py.test instead of an XUnit-based system, which gets rid of the stupid cruft of XUnit. This isn't a criticism of Rails or Ruby, per se -- we have the same module in Python and it's no better. py.test is much better, though.

Second, setup is done in paste.tests.fixture.setup_module, which is a special function that py.test calls (and you imported with import *). This finds your configuration file and creates your WSGI application. This part (finding a configuration file and using that to construct an application) is Paste-specific, but everything else sticks to WSGI. This also puts app (an object intended for testing) in the module's namespace.

Lastly, this object assumes when you say app.get('/') that you expect everything to work. That means a 200 OK response (as well as a couple other checks -- redirects are also okay). You have to specifically indicate that you expect another response; since this is an object intended for testing, why not build test-friendly assumptions into it?

Looking through the Rails docs on this, there's some other useful features I'd like to add. Because this only uses opaque WSGI applications, you can't look at the variables used to render the document; the only communication you get is the actual textual response. Here's what I frequently do:

def test_index():
    res = app.get('/')
    for item in db.TodoItem.select():
        res.mustcontain(item.title)

I'm not actually that interested in how the view got the items, so looking at the communication between view and controller isn't that interesting. But I can imagine adding some convention so that frameworks (when run in testing mode) could stuff objects into the WSGI environment for later inspection.

One of the things I like about Paste's tests compared to tests that are more opaque (e.g., actually speak to the app over HTTP) is that I have access to the backend objects (like db.TodoItem), and exceptions propogate (which gives me py.test's fancy tracebacks). As a result I've become less excited about the functional testing provided by Twill and others.

The whole thing is fairly young, but I think it is pleasantly simple and yet quite useful. If you are interested look at the docs.