John Lee wrote on 10/08/2005 12:50:43 PM:
> Here are a few more ideas
>
> - Tables mode
...
> I think I'm +1 on "Tables mode" until persuaded otherwise.
Okay, I'll take a crack at it. :-)
I started a thread on this back in March... I don't think we decided on anything... even though we all agreed the current names suck.
http://lists.public.thoughtworks.org/pipermail/selenium-devel/2005-March/000167.html
In conversation, I never use the phrase "TestRunner" mode.. If anything, I most often use the phrase "FIT style Selenium"* or "Python scripted Selenium". (Selenium originally started out as an attempt to implement FIT for _javascript_ in the browser. (http://fit.c2.com))
Anyway, I think we should use the same terms used by the SOAP and REST guys --- Document vs RPC.
TestRunner mode tests (aka "tables mode") are "document literal" -- they are delivered to the browser, parsed, and interpreted as "whole" documents.*
Driven-mode tests are RPC (Remote Procedure Call) -- these tests only send one command at a time to the browser, which I think is the truest meaning of "RPC".
Here's a good link describing the difference between "document literal" and "rpc":
http://www.devx.com/enterprise/Article/10397/0/page/3
So we have:
1) Document Literal Selenium
and
2) RPC Selenium
Document Literal Selenium can have several "encodings":
1) HTML table
2) _javascript_ + HTML table
3) Wiki table
4) "twill style" (see--> http://www.idyll.org/~t/www-tools/twill.html#what-is-twill)
(Only encoding #1 is currently supported, but I'd like to support 2,3,4 someday)
RPC Selenium can be written in Ruby, Python, Java, C#, Perl, Squeak, etc. The distinguishing feature is that some remote program is "remotely" making a "call" to the browser to execute a "procedure".
I really like "document" vs "rpc"... I can see the issues with those two type of web services apply to Selenium. With "Driven Selenium"-- the scripts are tightly coupled to the API in the browser.. If the API changes, the "Driven" driver needs to be updated, too. API changes are annoying, (just like with real-life SOAP RPC web services!) This tight coupling can be brittle and finicky. "Document literal" Selenium tests, on the other hand, are durable and have all the benefits of "documents"-- they can be emailed, downloaded, edited, uploaded, and verified. You don't even need a server process to execute a "document literal" Selenium test in the browser.
- Jason
_______________________________________________ Selenium-devel mailing list Selenium-devel@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-devel
