[Seaside] Re: Web app Testing frameworks

Julian Fitzell julian at beta4.com
Fri Jun 4 23:05:26 CEST 2004


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.

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.

Julian

Colin Putney wrote:
> 
> On Jun 4, 2004, at 1:23 PM, Roger Whitney wrote:
> 
>> Some of us in San Diego have been talking about the lack of testing of 
>> Smalltalk Web apps. Have you thought about something like HttpUnit 
>> where the tests are run on the results of http calls to the server? 
>> Such a framework would not be restricted to testing Seaside apps. 
>> Since one would be testing the http output the tests should give a bit 
>> more coverage of the web app but also make it harder for the tests to 
>> access the state of objects.
> 
> 
> Hi Roger,
> 
> I'm not sure that approach would work all that well with Seaside.
> 
> Seaside URLs are aren't references to specific pages or components, but 
> rather references to computational resources - continuations that can be 
> invoked by an HTTP request. Because of this, it's quite difficult to 
> write tests that drive the application via HTTP.
> 
> Now, Seaside does have the ability to create "bookmarkable" URLs, which 
> do refer to specific entry points in the application. We might be able 
> to use this to create entry points that could be used for testing. 
> Another approach would be to create a special testing version of the 
> application that provided urls to all the components where the test 
> client could find them.
> 
> I don't really see the value in that approach, however, since if you 
> have a special testing version of the application, you aren't really 
> testing it "in situ" anymore. And if that's the case, why go to all the 
> trouble of testing via http? Even if we're doing black box testing (not 
> looking at the internal state of objects) there's a lot to be gained by 
> having the tests run in the same image as the code under test.
> 
> 
> Colin
> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside


More information about the Seaside mailing list