Re: [Wheat-developer] comments on template attributes syntax

[Kragen S. <ksi...@co...>]

On Wed, 2005-04-06 at 11:49 -0700, Donovan Preston wrote:
> On Apr 6, 2005, at 9:10 AM, Mark Lentczner wrote:
> > Everyone 
> > seems to say that of course you should do it, then throws their hands 
> > up and says "oh well, the best we can do is lots of string matches".  
> > At best some people do lots of XPath or DOM based tests.  They all 
> > acknowledge how brittle it all is, and simply shrug.  Or those suggest 
> > that the final template layer be very thin and not tested.  I think we 
> > have the opportunity to do something much better here.
> 
> I have implemented 4 functional testing frameworks for woven/nevow from 
> the ground up:
> 
> - One which used twisted.web.client and twisted.web.microdom (for 
> woven, unreleased (probably included in very old quotient))
> - One which used newclient (never finished) and twisted.web.microdom 
> (for nevow, unreleased (probably included in old quotient))
> - One which used mechanize_ (quotient.test.webtest for quotient)
> - One based on ideas from selenium_ which uses livepage and a bunch of 
> javascript (nevow.livetest for nevow 0.4)
...
> The first three frameworks used some sort of HTTP client library and 
> parsed the resulting HTML. The selenium/livetest approach is to instead 
> tell the browser to fetch a URL and perform some assertion for you. 
> There are big advantages and some disadvantages to this approach, but I 
> believe it is the only sane way to perform web functional testing.

I was pretty happy with WWW::Mechanize in Perl --- better than any
alternative I'd tried.  I'm delighted to see a Python version.

My experience with writing HTTP functional tests, for one particular
large application and for a bunch of embedded web-server systems that
did basically the same thing, was that the "invisible" details of web
pages changed a lot more than the "visible" parts.  Divs would become
paragraphs; single pages would split into frames; links would become
form submit buttons; template variables would be renamed or recombined;
form fields would be renamed; etc.

I spent a little time comparing WinRunner against Mechanize.  WinRunner
drives an Internet Explorer browser, much as Selenium does, while
watching what you click on and type into.  It remembers some large set
of properties of the things you click on, and when running the test
script later, it uses this large set of properties to guess which object
on the new page corresponds to the one you clicked on while recording
the script, if any.

I think I would have recommended using WinRunner, despite its inability
to abstract out parts of a test, if we could have run it using Mozilla
under Linux (in, say, Xvnc or Xvfb).