[Seaside] Re: Web app Testing frameworks

Colin Putney cputney at wiresong.ca
Sat Jun 5 01:01:40 CEST 2004


On Jun 4, 2004, at 5:00 PM, Roger Whitney wrote:

> I was thinking that the HTTPUnit like test would be run in the same 
> image as the Seaside application. It would request the  page via HTTP. 
> It could still follow links or send forms using the encoded urls. I 
> was hoping that one could then use the url encoding to directly access 
> the objects in the session. (The server has to do this so it should 
> not be hard to get access to the server side objects with this 
> information by tests running the same image.) This would allow you to 
> make assertions about current state of server objects. This would 
> require starting at select entry points to the web application. I see 
> doing tests at the component level. So I see the framework allowing 
> one to create an entry point for the given component.

[snip what I wrote]

> I agree that one wants to avoid testing code in a special testing 
> environment to avoid differences between the test environment and the 
> actual environment. Using a MockRenderer seems like a creating a 
> special testing environment. That is why I was looking at using http 
> to access pages from the application, but in the same image. One 
> should be able to still tie the tests to the halo system to run the 
> tests on a given component.

Well, now I'm confused. I see two possible approaches here.

One is to take the black box idea to it's logical end and test strictly 
via HTTP. The user, through her UserAgent, can send HTTP requests and 
examine the results, so that's all we allow the tests to do. This has 
the advantage that the tests are extremely robust. The server can be 
rewritten from scratch using Lisp for all we as testers care, all that 
matters is the HTML that is produced.

The other is approach is to  deconstruct the application and test each 
component in a carefully controlled environment - almost a laboratory. 
This is the traditional SUnit approach, and has the advantage that we 
can make use of the Smalltalk development tools while testing - failed 
tests throw up debuggers for example.

The two approaches are both quite effective, and compliment each other 
nicely. XP gurus typically recommend both types of tests for different 
purposes. I think trying to combine the two strategies will only saddle 
us with the disadvantages of both, without providing corresponding 
benefits.

What I proposed in my first message was definitely the laboratory 
approach - dissect the app and test each component in isolation. Using 
a MockRenderer is certainly creating a special testing environment - 
one which allows us to detect and fix bugs quickly and efficiently. But 
if you're going to be mucking about in the session, examining objects 
directly, what's the point of accessing the app via HTTP?

If you want to test the frameworks as well as your app, it's a simple 
matter of programming to write SUnit tests for Seaside and 
Comanche/Swazoo/whatever. Avi doesn't seem interested in doing that, 
but there's no reason it couldn't be done.

I think there's a role for both approaches, and a truly well tested app 
would have both kinds of tests. But they ought to be completely 
separate.

Colin



More information about the Seaside mailing list