题目规则很简单：

1. 游戏开始后，系统会随机给出四个不重复的数字。由用户输入自己猜测的四个数字。
2. 如果数字猜对而且位置也对，就是1一个A。
3. 如果数字猜对但位置不对，就是一个B。
4. 返回结果是如“2A1B”这样的字串。
5. 猜错6次，游戏提示结束。重来。

开始提出的要求简单：用TDD驱动出实际代码。

大家抽签后开始pair，Yuheng还会一边计时一边催促，pair的气氛基本保持紧张有序。

在我和XuChen pair开始代码后，我们很容易写出第一个测试1，期望返回结果是”4A0B”，最简单的代码实现让测试变绿。

当我们试图写下第二个测试2，试图期望返回结果是“2A1B”时，我们发现不得不面对如何这个游戏规则的最核心算法，但可惜的是，猛然间对这个算法没有头绪。

局面一时僵住，停顿了有两分钟。

直觉和一点经验告诉我们，这时该拆解任务了。很容易想到，如果计算出几个A和几个B是很直白的拆分。

我们可以很容易写出一个测试3，测试猜测的四个数字跟事先给定的四个数字相比，有几个A类数字（循环比较），我们称之为perfect number。

也很容易写出另外一个测试4，测试猜测的四个数字跟事先给定的四个数字相比，有几个B类数字（在上个算法的基础上再循环比较），我们称之为good number。

写完针对测试3和4的实现代码，我们发现我们已经完成了最基本的算法，功能完成了。剩下的是重构代码。

从我们这次的经验看，我有一些收获和心得：

1. 测试就是代码的设计，你看测试3和4导致的结果就是我们有了对应的两个计算方法。你打算怎么测，你的实现代码就会是怎样的。
2. 印证了在Wikipedia中那段话，pair programming尤其适合面对一些challenging的任务（至少开始的时候是）。
3. 分解任务是王道。我们在不同的level拆分任务，从story拆分成task，从大问题拆分成小问题，莫不如是。
4. 囿于经验，不期望由端到端的测试能逐步甚至一下子推导出完整、完善的代码实现。而这样的练习，恰恰是我们锻造自己经验必不可少的过程。

我们在实现代码时，仍然欠缺的是：

1. 对于测试方法名的命名，不够清晰直白。
2. 对于算法代码的实现，简单粗糙，还需要重构。

查了查资料，过程如下：

1. 创建本地repo

localhost:~ twer$ cd
localhost:~ twer$ svnadmin create SVNRepo

2. 修改两个conf文件，打开访问权限，并添加授权用户

localhost:~ twer$ cd SVNRepo/
localhost:SVNRepo twer$ edit conf/svnserve.conf
localhost:SVNRepo twer$ edit conf/passwd

3. 创建trunk目录

localhost:SVNRepo twer$ svn mkdir file:///Users/twer/SVNRepo/trunk -m "create trunk"

4. 创建测试文件，并import到trunk

localhost:SVNRepo twer$ touch test.file
localhost:SVNRepo twer$ edit test.file
localhost:~ twer$ svn import test.file file:///Users/twer/SVNRepo/trunk/test.file -m"import file"

5. 启动svn server

localhost:~ twer$ cd SVNRepo
localhost:SVNRepo twer$ svnserve -d

6. 转移到working directory，checkout trunk

localhost:working_dir twer$ svn checkout svn://localhost/Users/twer/SVNRepo/trunk trunk

7. 新建branch

localhost:SVNRepo twer$ svn copy svn://localhost/Users/twer/SVNRepo/trunk svn://localhost/Users/twer/SVNRepo/branch -m"create branch"

8. checkout branch到新的branch目录

localhost:working_dir twer$ svn checkout svn://localhost/Users/twer/SVNRepo/branch branch

9. 修改test文件，提交

localhost:branch twer$ edit test.file
localhost:branch twer$ svn ci -m"change test.file"

10. 回到trunk目录，merge branch的变化

localhost:trunk twer$ svn merge svn://localhost/Users/twer/SVNRepo/branch

Some authors^[1] draw a distinction between fake and mock objects. Fakes are the simpler of the two, simply implementing the same interface as the object that they represent and returning pre-arranged responses. Thus a fake object merely provides a set of method stubs. In the book “The Art of Unit Testing”^[2] mocks are described as a fake object that helps decide if a test failed or passed, by verifying if an interaction on an object occurred or not. Everything else is defined as a stub. In that book, “Fakes” are anything that is not real. Based on their usage, they are either stubs or mocks. Mock objects in this sense do a little more: their method implementations contain assertions of their own. This means that a true mock, in this sense, will examine the context of each call— perhaps checking the order in which its methods are called, perhaps performing tests on the data passed into the method calls as arguments.

这里还有StackOverFlow的回答。 扩展阅读：

• Mock不是测试的银弹，胡凯，InfoQ
• 不要把Mock当作你的设计利器，李晓，CSDN
• Mocks Aren’t Stubs，Martin Fowler

说的简单点，就像开网吧，你需要对网吧的每一台机器安装操作系统，配置完全一样的软件，比如QQ和360，供网友上网，在系统和软件有损坏时，很简单的一个恢复操作就可以让机器回到刚刚安装好操作系统和软件的状态。

Puppet就是可以干这个事儿的，不同在于，Puppet是给网络管理员用的，而针对的系统多是*nix系统，因为Puppet目前对Windows支持的很少，但这不妨碍Puppet成为DevOps实现过程中的利器，另外一个类似的工具是Chef。

Puppet本身基于Ruby实现，但即使没有Ruby的经验也没甚大碍。Puppet自己提出了所谓Puppet Language，是一种DSL（Domain Specific Language）语言，用直白而描述性的语言，定义系统应该具有的状态，比如一个简单的例子tmpfile.pp：

file { 'testfile':
    path => '/tmp/testfile',
    ensure  => present,
    mode    => 0640,
    content => "I'm a test file.",
}

在安装了Puppet了机器上运行：

puppet apply tmpfile.pp

结果就会在/tmp下新增加一个testfile，内容是This is a test file。
这个例子太简单。除了file这种类型外，Puppet提供了大量的资源类型，供对系统的状态进行描述，比如打开（如果不存在会自动下载）某项服务，自动增加一个用户。当管理的机器成百上千，这样的自动化服务达到的效果就很可观了。

puppet apply是Puppet在单机上运行和测试的工具，真实的使用情景会是，一台机器（master）专门保留所有机器配置管理的状态信息，而每台机器（agent）会在指定的时间向master发起查询，从而更新自己的系统状态，以期与指定状态保持一致。

有个小需求是，在B中希望显示一个页面，根据参数能展示出不同的信息。这个页面在A中已经存在，所以自然而然最快的方法就是在B中创建一个iframe来指向那个A中的页面，配以不同的参数，多快好省！

问题很快出来了，QA发现那个iframe中的A页面很快就会session timeout，然后会提示用户输入登陆用户名和密码，而iframe外的B session并未过期的。

问题在于A和B实际上还是两个Web App，各自有各自的session。因为不能简单地修改A的页面，让它保持session不会timeout，所以剩下的办法只好是控制B的session timeout时间要早于A了。还有什么更优雅的方法呢？

如果给我一次重新实现的机会，我宁愿自己画一个属于B的页面，而扔掉iframe。

另外一个需求是，A和B是各自独立的Web App对于用户是透明的，用A的用户登陆进来可以直接进入B，反之则不可以。解决办法有点tricky，A的contextRoot设为/，B的contextRoot设为/XXX，这样二者的servletContext为同一个，即可实现A把自己的loginToken放到servletContext中后由B访问到，从而在请求B页面时，检查是否能取到servletContext中的loginToken，如果不能则转向到A的登陆页面，这点由Filter来实现。

Gets the result of evaluating the specified JavaScript snippet. The snippet may have multiple lines, but only the result of the last line will be returned.

Note that, by default, the snippet will run in the context of the “selenium” object itself, so this will refer to the Selenium object. Use window to refer to the window of your application, e.g. window.document.getElementById(‘foo’) If you need to use a locator to refer to a single element in your application page, you can use this.browserbot.findElement("id=foo") where “id=foo” is your locator.

The special thing here is the this reference, means when invoking method get_eval() to run some javascript snippet, the this reference in snippet would refer to (redicted?) caller Selenium object but not the original belonging object.

This does differ from what we already know for window.eval() method, in which javascript snippt this still refer to the original belonging object, see below demo code:

var a = 0;
window.eval("this.a = 1"); // this refers to window object
alert(a); // a=1
alert(this.a == a) // true

Above code demos this is window object itself.

function A(){};
A.prototype = {
  f1: function(){
    return "f1";
  },
  f2: function(){
    alert(this.f1());
  }
}
var a = new A();
window.eval("a.f2()"); // equals to a.f2(), this in f2 refers to a.

Above code demos this in a.f2() method still refers to a, but not window object.

Generally, eval() is an evil thing.

Design Pattern是针对特定问题的特定解决方案。

是问题，而不是解决方案定义了Pattern。

模式之间存在相似性，比如Adapter和Bridge模式，只是量的差别。

先让问题再想着怎么解决 over 想清楚什么问题再下手。

面向接口编程破坏了Communication和Technical之间的平衡。会带来Communication debt。

真的需要抽取借口时，需要两个条件：1. Concret Class；2. Consumer for Interface

没有bad smell就不要重构。

Pair是需要节奏的，为什么？最简单的回答是，没有节奏，两个人都会很累。我有体会，跟team另一个新TWer一起pair，两个人会不由自主地坐在屏幕前，切分任务，你写测试我写实现，一动不动坐了整个下午，除了上厕所的时间。可想而知，离开办公室的时候那个疲惫。

不是说Pair就会比一个人“裸奔”轻松，恰恰相反，Pair就会比较累，这是无数人经验证明的。但是我们仍然需要在Pair时控制一定的节奏，不仅仅是为了减轻疲劳。

最直觉的反应是，疲劳会影响对问题的考虑，测试的覆盖度，代码的质量，这在一对Pair都疲劳的状态下，也不能免俗。当疲劳把Pair能带来的那些个好处统统赶跑后，Pair还有何存在的意义？

一般来说，对Pair经验比较少的人，节奏可以由Pair经验多的人来控制，如何划分任务，粒度以及驱动测试开发的频度如何，都可以依据Pair的双方的能力和经验对比进行安排。在划分任务和思考时，可以以提问的形式，互相提问回答，推动进度。实现代码时，可以以乒乓的形式，由一方来编写测试，另一方编写实现，并跨任务轮换，让双方都感觉到Story的实现在有条不紊地前进，充满自信。双方可以约定在一个小时左右的时间，进行一次短暂的休息，切换context，以确保有持续的精力投入后续的Pair。

因为Pair是两个人的事情，当一方因为某种原因感觉到疲劳，或者被第三方事情打扰，不能集中精力在pair中时，可以主动跟对方提出中断，以换取集中的注意力在Pair上。

如果Pair对于某个问题或技术都不熟悉，并且在可遇见的时间内无法解决，应该立即寻求有经验同事的帮助，或者暂时放下留待后期解决，坚持钻牛角尖无疑是破快Pair节奏的杀手之一。就我的经验看，Pair时钻牛角尖的几率很小，在一方出现端倪时，对方会明显感觉到并主动提出来跳出这个圈子，这应该时Pair时一个小小的好处吧。

至于可能破坏Pair节奏的另外一个杀手——两人就问题或技术有争执，一般会发上在没有较多Pair经验的人身上，这会是另外一个话题，涉及到Simple Design，徐叉教导我们，要用代码证明自己的观点，要反过来关注问题本身。

对于Ruby小白的我，跟着QA一起学了一把。

• Ruby的包机制，应用的配置环境
• Selenium RC的原理，包的四个变种。
• 在07年就提到过的Page Object

自动化测试具备怎样的特质，才能最大限度的减少QA手工测试的工作量？

1. Effective
2. QA manageable

最后，徐X介绍了几个月前他研究出的Data Flow大法。简言之，测试不是要去测试事情本身，而是要测试事情结果的确发生。听着象废话，但那张精美手绘图却惊艳得不行。用以作为切分并归纳测试案例的依据。很受用，争取撺掇一篇文章出来。