[Seaside] Re: Web app Testing frameworks

[Colin Putney]

On Jun 4, 2004, at 4:05 PM, Julian Fitzell wrote:

> There's a tool called WebLoad that we discovered here at UBC (they 
> have a site license for a couple of seats).  It also has support for 
> some kind of assertion tests, but I haven't looked into it much.  
> WebLoad could be made to work pretty easily with seaside apps (needed 
> to add unique IDs to forms -- this may have been ported to 2.5 
> already) and did a really great job of identifying the correct links, 
> form fields, etc. even though the links were already changing.

How did it solve the problem of navigating to the page with the 
component? Did you create special entry points, use the ones you 
already had or what? Can you write tests that simulate a user?

> I'm given the impression that the licenses are insanely expensive, but 
> it might we worth having a look at for some people...
>
> Also just a sign that it *can* be done if you want to put in the 
> effort, I suppose.

Yeah, it's clear that it will take a fair amount of effort to test a 
Seaside app, no matter what the approach. The question for me is "What 
would be be most useful in the long run?"

Testing via HTTP
	- guarantees end-to-end black box tests
	- insulated from code churn in the Seaside framework
	- can also be used for load testing
	- can also be used to test non-Seaside apps

	- can only test pages, not individual components
	- will encounter difficulties caused by continuation-based urls

Testing via halos
	- tests can be written by non-programmers
	- tests can target individual components, but still occur within the 
surrounding page context
	- tests can take advantage of Smalltalk reflection - mocks, debuggers 
etc.
	
	- the testing framework can be broken by changes in Seaside

Colin