[Seaside] Re: Web app Testing frameworks

[Roger Whitney]

On Jun 4, 2004, at 1:16 PM, 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.
>
Hi Colin,

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.


> 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.
>
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.

----
Roger Whitney              Department of Computer Science
whitney at cs.sdsu.edu        San Diego State University
http://www.eli.sdsu.edu/   San Diego, CA 92182-7720
(619) 583-1978
(619) 594-3535 (office)
(619) 594-6746 (fax)