Re: [TFUI] TFUI for web applications -- writing reveal() methods

Oh. So using Watir in interactive mode is sort of like using reveal. Or you 
could just put a "wait for user input" in your test script, so the answer to 
the initial question is probably: Use Watir. Watir seems to be answering a 
lot of questions these days.
 Mike

 On 8/25/05, Phlip <[email protected]> wrote: 
> 
> Jim Shore wrote:
> 
> > Have you looked at NUnitAsp (nunitasp.sf.net <http://nunitasp.sf.net/>)? 
> It handles postback,
> > custom controls, etc. While it doesn't yet support reveal(), that's
> > something that could be added by someone sufficiently knowledgeable in
> > IE, and I would happily integrate such an addition.
> 
> Hmm. I always thought reveal() should be application-specific.
> 
> The reveal() for IE's DOM would just be spIE->Visible = true;, except
> reveal() _should_ block the test case until the user dismisses the
> revealer. That rule is optional so long as the visible web browser
> does not resume running all its other tests in your face before you
> can review the current situation. You can fix that by calling exit()
> to whack the test cases after the browser reveals. _That_ breaks the
> rule that after you close the revealer the current test case resumes
> its activations and assertions.
> 
> Next, if you simulate a browser (like with HttpUnit), you can put
> together another incomplete reveal() by writing the current page's
> HTML to scratch.html, and raising this in a browser. This technique
> discards DOM interactivity (the simulated JavaScript might not run),
> and it requires scratch.html can see relative paths to its support
> files, such as "/images/penBird.png" or
> "/scripts/myFavoriteScripts.js".
> 
> Such a reveal() can position scratch.html within a known repository of
> such files (the cheap fragile way), or it can download and refresh all
> these files dynamically (the expensive and still fragile way).
> 
> So, an application-specific reveal() could perform just enough of its
> requirements to reveal the tested GUI, and propel development. A
> generic reveal() must satisfy enough of these requirements to not slow
> most kinds of site development down, and must be flexible enough to
> accept application-specific fixups.
> 
> So, inconclusion, I suck at productization. Jim Shore might possibly
> be a little better at it, so go for it! Nobody is _required_ to use a
> default reveal(). Sometimes I just Tidy and dump the HTML, and read
> it...
> 
> -- 
> Phlip
> http://www.c2.com/cgi/wiki?ZeekLand
> 
>


[Non-text portions of this message have been removed]



------------------------ Yahoo! Groups Sponsor --------------------~--> 
<font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12h28jbrg/M=362131.6882499.7825260.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1124990337/A=2889191/R=0/SIG=10r90krvo/*http://www.thebeehive.org
">Get Bzzzy! (real tools to help you find a job) Welcome to the Sweet Life - brought to you by One Economy</a>.</font>
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/