Home Original page

Alternatives to WebUnit

John J. Lee jjl at pobox.com
Mon Oct 20 08:02:00 EDT 2003 
Ian Bicking <ianb at colorstudy.com> writes:

> On Monday, October 20, 2003, at 01:16 AM, Ben Finney wrote:
> > Howdy all,
> >
> > In searching for tools to run automated regression tests against a Web
> > aplication, I found (amid a number of tools requiring non-free Java)
> > the
> > WebUnit code:
> >
> >     <http://webunit.sourceforge.net/>

Horses for courses, I think: it all depends on what you're testing.
For lots of tests, there's no need for any HTTP traffic at all, of
course -- a lot of testing can and should be internal to your web
application.  For the rest, in a lot of unit tests it doesn't matter
how faithfully the client mimicks a real browser.  For other tests,
you'd be a fool not to do it by automating Mozilla or Konqueror or
MSIE (as many as you can be bothered to test).  An example: a while
ago, my HTML Forms code (ClientForm) had utterly broken file upload
code.  OTOH, I had several happily passing unit tests -- the problem
was that I was testing against Python's cgi module rather than a
'real' server (of course, I was well aware of this possibility, or
rather likelihood -- just hadn't got round to testing on more than one
'real' web server).  Of course, in that case, both the server and the
client were not 'real' (ClientForm replaced a browser, cgi module
replaced the server & web app framework), but the point's the same
whatever server you're using.

Actually, it's worth remembering that, when you're doing HTTP requests
direct from Python (rather than automating a browser), you might well
be able to do everything you need using only the standard library.
urllib2 (GET / POST with redirections, proxies etc.) plus
urllib.urlencode (for HTML forms &c) will do just fine for a lot of
stuff.  The major things that other code will buy you (I think) is
cookie support and HTML forms parsing and abstraction (and embedded
script interpretation, but you'd have to use Java or a browser for
that ATM -- there's no stable Python code to do that).  Oh, and easy
parsing of whatever else you're interested in from your HTML -- I
think DOM is easiest for that in some cases, HTMLParser or regexps in
others.  Somebody here had the nice idea of using lynx for parsing
tables.

In particular, then, webunit.sf.net is simple (good) but doesn't have
a very good cookies implementation.  IIRC the forms interface is a bit
low-level for my taste (but that *is* mostly a matter of taste -- I
hate all the messy details of HTML forms, so wrote ClientForm to hide
it behind a consistent interface).  Also IIRC, webunit & co. don't
parse forms, which you may or may not want.  I don't think old-webunit
is actively maintained.  There's some good Java code out there, but
you say you don't want that -- fair enough.  I've never used the other
webunit, and I forgot about puffin until this thread, so I can't
remember a thing about it.  :-)


[about the new webunit]
> There's another bit of code going by the same name at
> http://mechanicalcat.net/tech/webunit -- I haven't tried it, so I

Could anybody send me tarball?  The link to the .tgz is broken.


[about the old webunit]
> > Unfortunately, the code is somewhat beta and doesn't seem to have been
> > updated since 02-Feb-2002.  Does anyone know if this has been updated
> > since, or merged into some other project?
> 
> Last time I looked at it, it didn't look like there was any movement,
> and that was quite a bit more than a year ago.  What I remember that
> webunit implementing -- mostly just httpsession -- is better
> implemented elsewhere now (ClientCookie and ClientForm might be good
> things to look at).

Yes, that's certainly true of cookies, HTML forms is more a matter of
taste and whether you want to do form parsing as part of your tests.
Lots of people just use urllib.urlencode for that.

But I wouldn't be surprised if this new webunit (the one at
mechanicalcat.net) actually uses some of my code 'under the hood'.
Certainly anybody writing their own cookie handling code is a
masochist, IMNSHO ;-) If so, I guess it's a matter of taste again
whether you use the underlying modules or prefer a framework on top.


John
More information about the Python-list mailing list