[Seaside] onAnswer: problems

[Avi Bryant]

On Jun 20, 2004, at 11:04 PM, C. David Shaffer wrote:
> testBack
>    | result |
>    self newApplicationForComponent: SCTestComponent2.
>    result _ self establishSession.
>    result _ self
>                followAnchor: (result anchorNumber: 1).
>    self assert: self component firstSent.
>    self deny: self component secondSent.
>    result _ self
>                followAnchor: (result anchorNumber: 1).
>    self backAndRefresh.
>    self assert: self component firstSent.
>    self deny: self component secondSent
>
> So "self component" always answers the component used the render the 
> last request (although frankly I have no idea if my code for that is 
> correct).  Anyway, I'm sure that you get the idea.  I realize that 
> this kind of test is not designed to indicate static structure of the 
> rendered component but my GUI tests don't check how my GUI component 
> was painted either.  I also understand that there are lots of tools 
> that need to go around this (to aid in test generation etc).  If there 
> is any interest in this testing framework, I will fill in the gaps, 
> clean it up and put it on SqueakMap.

This looks like a good approach.  It's very similar to something I 
played with, and liked, a while ago, which was a little more white-box: 
my tests looked much like yours, but instead of #followAnchor: I would 
just directly send #sendFirst and so on.  That's less fragile if the 
rendering changes and anchors get reordered or changed to buttons, etc, 
but your approach is better able to simulate a user agent (I love 
#backAndRefresh), and you still get the direct querying of the 
component state, which I think is important (vs. Nori or HttpUnit, 
where the assertions are about the HTML rather than the objects).

It should also be possible to write tests in this style that exercise a 
large portion of the framework, which would be very nice to have for 
ports.

So, by all means, continue working on it.

Avi