[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