Selenium分为两种运行模式，Driven Mode(现在叫Selenium Remote Control)和FIT Mode(现在叫Selenium Core)。

FIT Mode顾名思义，就是类似FIT Testing Framework那种使用方式，主要用于QA等非技术人员编写Web应用的功能测试。FIT Mode的Selenium测试使用HTML来组织测试用例。例如我要测试一个web应用的登陆功能。我可能写出这样的HTML 表格。

 1 < table >
 2 < tr >
 3   < td > open </ td >
 4          < td > http://localhost:8080/login </ td >
 5          < td ></ td >
 6 </ tr >
 7 < tr >
 8   < td > type </ td >
 9          < td > id=username </ td >
10          < td > someuser </ td >
11 </ tr >
12 < tr >
13   < td > type </ td >
14          < td > id=password </ td >
15          < td > password </ td >
16 </ tr >
17 < tr >
18   < td > click </ td >
19          < td > id=login_button </ td >
20          < td ></ td >
21 </ tr >
22 < tr >
23   < td > assertTextPresent </ td >
24          < td > Welcome to xxxx </ td >
25          < td ></ td >
26 </ tr >
27 </ table >

不同于FIT，Selenium内置了一系列的命令，如上例中的open, type, click以及assertTextPresent，因此QA可以完全抛开DEV独立地编写测试(FIT需要DEV提供Behavior Fixture)。因此FIT Mode是相当容易使用的，哪怕不会使用HTML的QA，也可以使用FrontPage画出三列表格，依次填入数据。

然而对于大多数team而言——尤其是敏捷team，FIT Mode平易的外表下是令人恐惧的泥沼。大多数团队往往选择使用Selenium作为功能测试和集成测试工具而不仅仅是QA测试工具，在不同的迭代间遇到功能流程或UI变化时，必须要重构Selenium测试，或者说，Functional Test Migration。令人遗憾的是，HTML based的Selenium FIT Testing的重构竟然令人难以置信的困难。我们可以使用include等Selenium FIT扩展，使得它可以重用详细的功能（Log in， Log out诸如此类）。即便如此，在一个真实的项目中，Selenium Test的数量往往在200-500之间(我目前所处的项目在改用Driven Mode前已达350+)，对于这么大基数的Selenium测试，手工重构几乎是不可想象的，而目前尚没有HTML代码重构工具。即便存在泛泛意义上的HTML重构工具，对于Selenium测试重构的有效性尚待商榷。而使用Driven Mode上述代码可以写为:

1 public   void  testShouldShowAWeclomeMessageAfterUserLoggedIn()  {
2     selenium.open( " http://localhost:8080/login " );
3     selenium.type( " id=username " , " someuser " );
4     selenium.type( " id=password " ,  " password " );
5     selenium.click( " id=login_button " );
6     assertTrue(selenium.isTextPresent( " Welcome to xxxx " ));
7 }

很自然，一个训练有素的程序员会重构出如下代码:

 1 public   void  login(String username, String password)  {
 2     selenium.open( " http://localhost:8080/login " );
 3     selenium.type( " id=username " ,username);
 4     selenium.type( " id=password " , password);
 5     selenium.click( " id=login_button " ); 
 6 }
 7
 8 public   void  testShouldShowAWeclomeMessageAfterUserLoggedIn()  {
 9     login( " someuser " ,  " password " );
10     assertTrue(selenium.isTextPresent( " Welcome to xxxx " ));
11 }

之后无论是pull up到公共基类还是extact到Utils class都是很容易的事情。由于Java在代码重构上便利，Java Selenium Remote Control成为使用Selenium的最佳方式。在这一点上，纵使Ruby语法上比Java简单灵活得多，它仍不是编写Selenium测试的最佳载体(当然一个经过精心设计的ruby selenium dsl wrapper还是具有非凡的价值的，这个我们后面会涉及到)。

2. Using the name user, system, page instead of selenium

观察上面提到的代码，其中使用selenium来操纵web应用的行为，这在Remote Control里是常见的做法，但是仍然不够好，我们可以做一些小的变化以得到更好的测试:

 1 protected   void  setup()  {
 2     selenium  =    //  intialize selenium instance
 3     user  =  selenium;
 4     currentPage  =  selenium;
 5 }
 6
 7 public   void  login(String username, String password)  {
 8     user.open( " http://localhost:8080/login " );
 9     user.type( " id=username " ,username);
10     user.type( " id=password " , password);
11     user.click( " id=login_button " ); 
12 }
13
14 public   void  testShouldShowAWeclomeMessageAfterUserLoggedIn()  {
15     login( " some guy " ,  " password " );
16     assertTrue(currentPage.isTextPresent( " Welcome to xxxx " ));
17 }

基本上这只不过是"另一种写法"而已，但是它更好的表达了"用户的行为"，如login代码所示。以及"系统的正确相应"，即currentPage.isTextPresent()。这种是典型的对编译器无意义对人有意义的代码，也就是普遍意义上好的代码。

3. Creating a DSL base on your test codes

懂得HTML的QA可以在没有DEV的帮助下使用Selenium FIT mode，然而却不能在没有DEV的帮助下使用Driven Mode。于是最自然也是最fashion的做法，就是在已有的test codes之上提供Testing DSL或者Scripting Language，让FIT mode变得更加FIT。这方面内容是一个更大的主题，以后再详细展开吧。

4. Hacking Selenium Object to support FIT command

Selenium FIT mode和RC mode下的命令有些许差异，比如FIT中的assertTextPresent，在RC中变成了isTextPresent。同样还有FIT中最实用的命令clickAndWait，在RC中变成了click和waitForPageToLoad。在RC中使用FIT mode中的命令也非难事，找到com.thoughtworks.selenium.Selenium，添加方法:

public   void  doCommand(String commmand, String parameters);

然后在com.thoughtworks.selenium.DefaultSelenium中添加实现:

1 public   void  doCommand(String commmand, String parameters)  {
2    String[] paras  =   new  String[] { "" , "" , "" }
3     for  ( int  i  =   0 ; i  <  parameters.length  &&  i  <   3 ; i ++ )
4       paras[i]  =  parameters[i];
5    commandProcessor.doCommand(command, paras);
6 }

然后试验一下:

selenium.doCommand( " clickAndWait " );

在我们使用纯RC mode之前曾经用过一段中间方案，将rc code转化为fit code来跑(因为rc不支持https)，由于不是真正的rc mode，像isTextPresent之类的方法都没有办法使用，只能使用FIT mode command。因此如果因为一些特殊的原因(https, chrome起不来，hta bug多等等)，你没有办法使用RC mode，但是有希望得到RC可重构的好处，那么这个tricky的技巧倒是不错的选择。

5. Using chrome and IE hta lanucher to support https
6. Run test using different browser lanucher to test browser compatibility

这两个都是和browser lanucher相关的，Selenium和JWebUnit最大的不同在于它使用真实的浏览器来跑测试，从而可以更加真实地考察系统在不同浏览器中的表现。因此使用不同的浏览器lanucher来运行测试，可以更好测试应用的浏览器兼容性，这对于web 2.0应用而言是很有帮助的。此外，使用rc提供的试验性lanucher，chrome和hta可以解决跨domain测试和https的问题。不过目前hta还是有很多bug的，推荐使用chrome。当然，最希望的还是澳洲的同事可以早日在selenium里提供https支持。

老庄是反对一切皆对象的，而TrustNo1在javaeye的一篇帖子上说:

第一，我可以很负责的说,OO的，70年代成型，80年代在理论基础上就给人毙掉。从这种意义上说不是OO死不死的问题，而是OO还活着么？当然理论基础给人毙掉，不是说没有用。

我先说面向对象的理论基础的问题，至于一切皆对象稍后再表。

所谓面向对象的理论基础其实是没有的，原因很简单，面向对象根本就不是一种计算模型。在第一次软件危机的那个时代，对与计算机的非数值计算应用的讨论以及对于可计算性问题的研究和发展，大抵确立了几种主流的计算模型：递归函数类，图灵机，Lambda演算，Horn子句，Post系统等等。

其中递归函数类是可计算性问题的数学解释;图灵机是图灵解决可计算问题的时候所设计的装置，其后成为计算机的装置模型，与图灵机相关的形式语言和自动机成为了命令式语言的理论基础;lambda演算成为了函数式语言的理论基础;Horn子句是prolog这类逻辑语言的理论基础。但是我们惊讶的发现，面向对象没有计算模型的理论基础，换而言之，面向对象根本就不是从可计算性的研究上发展过来的，那么面向对象的理论基础的价值本身就不大。

所以我很奇怪的一个问题就是TrustNo1所谓的面向对象在80年代理论基础上给人毙掉的说法是从何而来的？既然面向对象本质上不是一种计算模型，那么它大抵上只能归结为一种应用技术，应用技术自然可以从各种不同的领域里得到相似的应用，那么毙掉的理论基础所指的又是什么呢？甚怪之。

既然面向对象不是一个计算模型，那么我们可以从不同的角度推断出OO的各种形态，老庄已经出给了从ADT引出OO的问题以及例子，我就不罗嗦了，我给一个从Functional Programming出来的例子，其实就是SICP里的Data as Procedure。

(define (make-user name age sex)
  (define (dispatch message)
     (cond ((eq? message 'getName) name)
           ((eq? message 'getAge) age)
           ((eq? message 'getSex) sex))
           (else (error 'messageNotUnderstand))))
  dispatch)

然后我们就可以

(define vincent (make-user 'Vincent 24 'Male))
(vincent 'getName)

自然的，如果我调用

(vincent 'sayHi)

会得到一个messageNotUnderstand的runtime错误，这就是一个很自然dyanmic type的对象封装，最早的面向对象系统Smalltalk和CLOS基本上都是这个路子，于是有一个问题，为什么最早的面向对象系统都是dyanmic type？这里就跟lambda演算有关了。

lambda演算这个计算模型根本的一个假设就是，对于任何一个定义良好的数学函数，我都可以使用lambda抽象来表述他的求值，因此无论是什么东西你能够构造lambda抽象的话，我就能计算。这个地方东西很多，大家可以找找lambda演算相关的资料，这里我说三件事(由于lambda太难输入，我用scheme程序代替，然后由于alpha变化，beta规约和eta规约我也用scheme伪码来模拟。)

第一个是数值的表述，其实这个很简单，不考虑丘奇代数的系统的话，我们可以把数值表示成单值函数:

(define one (lambda (x) 1))

这个东西无论给什么x都返回1，然后根据lambda演算里的alpha变换，这个lambda抽象等价于数值1。因此，对于所有的数值，我们可以按lambda演算处理。

第二个是bool的表达，也就是如何逻辑进行lambda抽象，下面我直接给出了，缺省认为大家都看了SICP，对Scheme也颇有心得。

(define true-new (lambda (x y) x)) ;;;这个函数也叫select-first
(define false-new (lambda (x y) x));;;这个函数也叫select-second

(define if-new (lambda (conditon if-true if-false) (condition if-true if-false)))

然后我就可以做一个测试

(if-new true-new 3 4)
3

(if-new false-new 3 4)
4

因此，对于所有bool我们可以按lambda演算来处理

第三个是自定义类型，这里我们还是先看一个Lisp里的例子，序对。