[Seaside] SeasideTesting released on SqueakMap

[C. David Shaffer]

Avi Bryant wrote:

>
> On Jul 20, 2004, at 1:16 PM, C. David Shaffer wrote:
>
>> This will be my last release for Seaside 2.5a5 since my extensions to 
>> WAHalo tend to be fairly version dependent.  There is still a fair 
>> amount to be done but I've been using it off and on for a couple 
>> weeks and I think that, if you're test infected, you'll find it makes 
>> a good framework upon which to build component tests.  Feedback is 
>> always welcome ;-)
>
>
> Wow.  I had a chance to take a look at this today, and it's a very 
> nice piece of work.  It's the only thing I've seen so far that makes 
> it seem like testing web UIs could actually be feasible.  I'll 
> definitely be demoing this the next time I do a Seaside talk.  
> Especially nice for demos (and for general use, I imagine) is being 
> able to browse through the history of rendered pages  - though it 
> would be even cooler if their links worked.

Thanks.  With the current version the session and app are gone at the 
time you view the page history but I should have that corrected soon.  I 
had a few other ideas for this feature too.  I should be able to single 
step through the test case while viewing the current response in a 
browser other than Scamper :-)  I can force mozilla to load a page under 
X using the "remote control" mechanism and while this might serve me 
well it would be platform dependent.  If I accept the client-pull nature 
of these browsers then I could devise a way that a client refresh would 
bring the user's browser to the current test browser's view.  So, you 
single step through your test and hit refresh on the browser when you 
want to see the current page.  Also, I've found that being able to 
compare what a browser submitted to the server with what a test case 
submits to a server has been useful during the development of this 
package but I'm not sure if it will be useful when testing components.  
I would at least like to display the request that the test framework 
used to generate the page so you could see GET and POST data.  
Unfortunately I don't save the original request, just the one that was 
generated by the redirect.  This is on my list to be fixed soon as well.

>
> One thing this encourages is adding good CSS ids throughout the 
> render, which is something that's always seemed overly clunky to me.  
> That is, the necessity to put #cssClass: and #cssId:, as well as 
> #div:, #span:, etc everywhere, clutters up the more interesting parts 
> (like anchors and callbacks) of any given render method.  Anyone have 
> any good ideas to keep these separated?  

> I'm just throwing out random thoughts here, but one possible pattern 
> that occurs to me would be to introduce a higher level wrapper around 
> the HtmlRenderer, that was specific to a particular component.  For 
> lack of a more imaginative name, let's call this a View.  The idea 
> would be that the *structure* of the rendering is still controlled by 
> the component, but the specifics (the actual tags and ids) are filled 
> in by the View.  So, for example, take the following fairly typical 
> render method:
> [...example snipped...]

I see how that helps a little with classes and document structure but 
I'm not sure if that helps with id's.  I like it somewhat because it 
offers one layer greater of abstraction on the renderer...something 
which I wanted when thinking about generating other types of content 
(mainly other XML doctypes).  So your application could have both an 
XMLView and a XHTMLView.   Actually XMLView should be more specific to 
the target DOCTYPE etc.  This kind of distinction doesn't seem possible 
with the renderer protocol which is more about XHTML generation.  
Anyway, this is off-topic a bit.  As far as writing small, testable 
components goes I don't mind the clutter of adding id's to my forms and 
input elements (most of the time I reference anchors by their text).  
Most of the time my renderContentOn: is split into several separate 
rendering methods as you do in several of your components.  While not as 
reusable as your "View" code, it keeps the clutter down to a minimum but 
has the advantage of keeping the generation of the component's portion 
of the content more localized in code.  Again, I like the View idea for 
other reasons.  Did the Seaside blog (Smallblog?) include generation of 
feeds in various syndication formats?  If so, how was that done?

David