路宁(luning)的博客

Mark Needham just posted a blog here described the 'waiting for jQuery ajax call' problem in selenium tests and the way we solved it.

The basic idea is recording the count of active ajax requests in client side js code, and generically decorating the calls(click, type, select etc.) in selenium tests with the logic of waiting for the count to be zero.

Ajax request may not be the only async point we want to wait for its completion in selenium tests, animation is another one we care about, but just turn off it in tests so that we don't need to worry about it any more. "jQuery.fx.off = true" will turn off jQuery animation.

Is there any more async points? probably YES. Acturally, what we really want to wait is the completion of any action which is delayed to be executed by window.setTimeout() or window.setInterval(). Ajax and animation rely on window.setTimeout() or window.setInterval() to simulate the async behaviours eventually.

Please check out the code at mark's post or here(with comments) for details. It works for the cases you fire multiple ajax requests at once or fire further ajax request in previous ajax request's callback.

Given this, we removed almost all noisy thread.sleep() and waitForCondition() codes in selenium tests! The build is speeded up and the tests become more concise, readable and stable.

This approach is simple, stable, side-effect free and able to be ported to other ajax framework easily.(jQuery Ajax provides proper events we can rely on, for other ajax framework without build-in events, we can try method delegation instead)

Waiting for ajax call is a common issue in selenium tests, try this approach and make your selenium tests cleaner.

I paired with Josh Price wrote the javascript code below, just before that we noticed something abnormal about event handling and wanted to find out what happened.

Just paste the code below into Firebug console of Firefox, run it, do something triggering events in page and watch the log printed out.

Please note that this requires jQuery.

var counter = 0;
$("*").each(function() {
  var events = $(this).data('events');
  if(events) {
    $.each(events, function(type, handlers) {
      $.each(handlers, function(i, handler){
        handlers[i] = function(){
          handler.apply(this, arguments);
          console.log(++counter, type);
        };
      });
    });
  }
});

 
You can add more logging per your need, e.g. the time used for each handler call.

Here is the way we used today checking the quality of client side javascript code.

Launch Firefox, access the site under developing, open Firebug console and run the scripts below:

 for(var property in window){
     console.log(property);
 }

 
We get a list of properties directly defined in window instance, which is the place where all global functions and variables exist.

Filter out the build in properties and the ones introduced by the external libs, like jQuery, Prototype, and we get all the global functions and variables defined by the team.

Then ask:

• Do we have too many of them and is it a sign of lacking encapsulation?
   
  
• Are all of them worth being introduced with global accessibility?

 
We really got some clues of refactoring, cool!

The key is that try object oriented javascript before the plain global functions and variables run out of control.

My Object Mother is easily messed up with overload methods

Object Mother is usually used as a test fixture to create objects for testing purpose. e.g.:

Contact contact = ContactMother.CreateContact();

A typical simple contact will be assembled through the call. As project goes on, ContactMother may probabily looks like below:

CreateContact(string firstName, string lastName)
CreateContact(string firstName, string lastName, string organizationName)
CreateContact(string organizationName, string email)
...

Every reasonable combination of parameters may want to overload the method. The class is messed up and becomes hard to use and maintain.

.NET 3.5 Object Initializer could do a better job than overload methods

Object Initializer is one of the language enhancements of .NET 3.5, you can create object like this:

SomeObject object = new SomeObject{Property1 = "foo", Property2 = "bar"};

It's a short version of creating object with default constructor and setting properties as your needs.

You may have the feeling that we could create our parameter combination with this much flexible manner.

Create an Object Builder which holds properties used for creating object

public class ContactBuilder
{
    public string  FirstName  {get; set;}
    public string  LastName  {get; set;}
    public string  EMail  {get; set;}
    public string  OrganizationName  {get; set;}
    // other customizable properties may be used by tests

    public ContactBuilder()
    {
        // set all to default value
        FirstName = "foo";
        LastName = "bar";
        EMail = "foobar@abc.com";
        OrganizationName = "ABC";
        // set other properties...
    }

    public Contact Build()
    {
        // create dependent objects including Organization
        // assemble the final contact with the properties and return it
    }
}

Then, contact can be created with any parameter combination:

Contact simpleContact = new ContactBuilder().Build();
Contact foobar = new ContactBuilder{FirstName = "foo", LastName = "bar"}.Build();
Contact contactWithOrganization = new ContactBuilder{OrganizationName = "Freeway"}.Build();
...

Combine with a Call-Chain style builder

Typically, Object Builder build object as below:

Contact contact = new ContactBuilder()
                      .WithName("foo", "bar")
                      .WithEmail("foobar@abc.com")
                      .Build();

The trick is obviously returning 'this' in all WithXXX methods.

The object initializer style builder is very similar as the call-chain style builder, and some time it's meaningful to combile these two. e.g. if you want to add common behaviours into builder as well, like this:

Contact foobar = new ContactBuilder{FirstName = "foo", LastName = "bar"}
                     .AttendAMeeting("Sales Meeting")
                     .Build();

书的全名是《丰田现场管理方式 - 丰田巨额利润的秘密》，日文翻译的，1978年出版，整整30年了。阅读过程中确实能感受到那个年代的“朴素”，而现代介绍精益生产的书则充满了“提炼与升华”。

该本介绍了丰田生产方式的方方面面，浅显易懂，而且介绍了很多工厂的具体实践，会把你带入生产第一线。照例，下面我把书中一些有意思的地方摘录下来。

• 商业活动中，购入物品被加上差价，形成销售价，...，企业收益并非来自于对消费者有意义的增值活动，而是把负担转嫁到消费者身上。这是一种反社会的现象。...

Burn down chart and story wall are often used in agile project for visualizing the status and progress of project. They should be designed to visualize smell easily as well.

Smell is sometime made less visible unintentionally. We probably did things as below:

• Enlarge the wall for more cards.
  The wall then became more 'smell tolerant'. Problems are hard to identify.
   
• Categorize bugs so that we can manage more.
  Feeling of bugs being well organized weakens the strength of the will to fix them soon. The count of half done stories may increase with the bugs.

 
So, in order to resist the tendency, we can try:

• End-to-end evaluating, keep goal in mind.
   
• Make it brittle for even small problems. Here 'it' fits for process, story wall and more.
   
• Keep it simple, less is more.
   

这是一个基于JSF的WEB应用，被测的场景是编辑一个巨大的表单，然后进行预览操作，最后再回到编辑页面，验证各个字段是否和以前的一样，据此间接检验各个页面元素与后台Bean的绑定是否正确。

以前的测试不是人读的

这是之前实现这一测试的代码片段：

@Test
public void createFullRequest_priview_backEditing_checkData(){
    goToCreationPage();
    browser.click(ADD_APPOINTMENT);
    browser.click("lorryTrucking1");
    browser.select("containerSizeType1_1", "label=20' Platform");
    typeAndBlur("containerQuantity1_1", "1");
    browser.select("cargoPackageType1_1", "label=Bar");

......

• 系统思考即整体思考，比较接近中国传统思考方式。在中国人的社会里，当你拿到一个物品时，大多问这是哪里来的；而在西方人的文化里，他们会问这是由什么组成的。
   
• 企业被分为几个独立部门，高级主管们整天关在会议室里......，技术部门......，质量部门......，各职能部门相互扯皮......“各司其职”的“后遗症”使我们几乎丧失了关照整体的能力，“过度分工”的结果是工作越努力，公司的利润就越低！
   
• 很多人存在这样一个逻辑，即认为只要每个人、每个部门都把目标达成，整个公司的目标就会达成。所以，只要公司目标没有达到，人们就会自然而然地反推一定是某个部门或某个人没有做好，只要将这个“害群之马”揪出来换掉，问题就会迎刃而解。只是真正的害群之马很难找到。扯淡！造成问题的关键是人们把整体简单当成部分的总和了，并由此导致对部门间互动和关系的忽略。
   
• 整体大于局部之和。
   
• 从根本上讲，管理只有两项工作：“踩下油门”（成长引擎）和“松开刹车”（消除障碍）。
   
• 对于很多团队而言，“我们可以一起唱歌、一起跳舞，却不能一起思考”。
   
• 系统的关键特征：
  1. 涌现：系统作为整体表现出来的个体不具备的特性。
  2. 自组织：动态的，高度有序的，开放的。
  3. 反馈：大量内部反馈机制。
  4. 能量流：做为开放系统需要持续注入能量，能量流过整个系统。
  5. 自修正：大量反馈回路的交互作用保证系统一定程度上免受外部冲击影响。

    飞行的鸟群、骑车人和自行车构成的系统、人本身、地球、合格的团队都是系统的例子。

• 系统的精髓就是它的组件之间的连接，而不是作为独立个体呈现出来的各种特性。
   

• 每位经理都尽职尽责地管理好自己的“一亩三分地”，然而，所有人都成功管理好自己分内的事情的结果，却通常是局部最优化。在大多数组织中，这通常都是组织结构和局部绩效评价措施的必然结果。......工厂经理们受到提高生产效率的激励，把车间填满成品，从而使之变成“市场销售的问题”。
   
• 理解动态复杂性并清楚地认识到其背后的模式及因果关系非常困难。从某种意义上说，人的思想确实更适合处理细节复杂性，即对某一时间某一地点的系统进行理解，尽管这时的系统由很多元素组成。
   
• 系统思考和系统循环图帮助你看到复杂现象背后的简单因果回路。
   
• 有时候“治标”确实比“治本”更有诱惑力。
   
• 在系统循环图中，是事实在说话，而不是我们的测量能力在说话。因此，只要它确实存在，就把它捕获并记录下来，尽管它可能是一个像“士气”这样的“模糊变量”。
   
• 就业务中的事务这一层次进行交流，无法达到创建高绩效团队的目的。我们必须进行更深层次的交流 - 必须在心智模式的层次上交流。系统循环图是实现这一层次交流的重要工具。
   
• 从个人风格和信念两个角度对计划方式作一个划分：
  
  
  
  
  1. 那些相信自己可以预测并控制未来的人是“上帝”。他们踌躇满志，知道一切问题的答案。他们根本不需要任何计划方法--他们就是有决断力。
  2. 那些希望授权但认为他们能够预测未来的人是“赌徒”。他们明白自己必会每注必赢，因此他们希望了解成功的机会有多大。赌徒们很欣赏财务分析。
  3. 那些希望授权但认为他们能够预测未来的人是“学究”。他们偏爱分析、方法、数据和技术，他们总在寻找“正确的”答案。他们是受欢迎的咨询顾问，总会有人愿意为最新的“管理潮流”买单。
  4. 最后一角留给“向导”。和学究不同，他们不相信仅仅因为掌握了正确的技术就能自然地发现“正确的”答案、相反，他们知道未来无法预测，他们试图引导自己的组织在各种不确定性间穿行。

前些天，客户的一个经理问我，来到ThoughtWorks前后自己有什么变化，当时说的都是和工作相关的，今天突然想记录一下自己在日常生活中观点的变化，这些都直接或间接地受到敏捷和精益思想的影响。

• 以前习惯每周坐车去大超市买一大堆吃的回家，买的时候都挺新鲜，吃得时候要留意一下是否已经烂了。现在更多是在楼下的小超市买东西，哪怕会有点贵。
   
• 以前溜达到超市库房，看到工人们忙碌在堆积如山的商品前装卸，觉得挺有意思。现在心里却想，老子付的账还要给这库房买单，还要给“装箱”、“拆箱”这类无聊的动作买单，心里不甘。
   
• 以前心理想着“十年磨一剑”，等我牛了之后吓死你们。现在琢磨出点东西就想到处去显摆。
   
• 大学四年，尽管大部分知识在工作上都用不上，但觉得这些知识对我应该是有些潜移默化的影响的。现在看来，这种想法就是扯淡，是给目前的高等教育找借口，学习本来就是一辈子的事，需要啥就学啥，用不上的东西就是浪费。
   
• 以前喜欢用大钱包，有用没用的都往里装。现在用一个极小的钱包，除了钱，只有两张卡和一个省份证。
   
• 以前攒一周的脏衣服，周末一起洗，现在天天都想洗，只是后悔买了那个5.5升的洗衣机，太费水了，很多只能手洗了。如果能有一个小的洗衣机，然后和邻居共用一个大的就完美了。
   
• 以前搬家的时候这个不舍得扔那个不舍得丢。最近一次搬家，东西扔的真痛快。去年春节回老家，真想把家里的“垃圾”都扔了，可是没法说服父母。我爸连我小学时候用的课本都不肯扔，说是要留给我未来的儿子用，汗。
   
• 以前到银行，在超市，深信“排队”是一种美德，现在更多的时候是在想“为什么还要让我排队啊”。
   
• 以前总觉得北京这三环四环不够宽。现在感觉很多路根本没利用上，很多“大院”、“小区”对公共交通一点贡献都没有。
   
• 以前感觉有个××商业中心、××展览中心和××CBD挺好。现在听到“中心”、“集中”这样的字眼心里就烦，好好的交通就坏在这些中心上了。

我说上面这些变化都和敏捷和精益有关，你信么？

回顾会议中的Safety Check

在敏捷项目回顾会议正式开始之前，我们有时会做个匿名的“Safefy Check” ，以了解大家在分享自己的想法时是否有“安全感”。一般分5个等级，1代表“我会微笑，说事情进展的不错，并同意经理的所有看法”，5代表“愿意敞开谈任何问题”。

这样做是让大家认识到，每个人心里的安全感是不一样的，组织者会据此变换会议的形式，以确保在达到会议效果的同时不让任何人感觉不舒服。

项目组中的Safety Check

同样的，在项目组中，每个人也都有自己的“安全感”等级。让我们试着回答下面的问题（每个问题的前一个选择表示你在团队中有较高的“安全感”）：

• 你是否愿意及时表达自己的意见，而不必担心会被指为是幼稚的想法。
• 在有疑问时，你是否愿意在第一时间找到对此问题最熟悉的人寻求帮助，而不管他/她是谁，也无需担心被鄙视。
• 在你做一些自己没有把握的尝试时，得到的常常是鼓励与指导，还是阻力或质疑。
• 在你做一个选择或决策时，考虑的是对整个团队是否有价值，还是更在意给项目经理或某一个人留下的印象。

对上面问题的回答可以反映出成员在项目组中的“安全感” 级别。当安全感等级较高时，团队的能动性和创造力可以被充分激发出来，团队成员工作起来也开心，幸福。相反，较低的安全感让人感觉压抑，要处处小心。“安全感”是主观的，无法强加的，也是团队建设的重要方面。

你在项目组中有“安全感”吗？

最近的一个Web项目大部分的逻辑都是客户端页面逻辑，主要是通过Javascript实现的，如何进行高覆盖率的单元测试是我们面临的一个问题。

分 析一下，有两种逻辑需要测试，一个是与服务器交互的页面操作，比如提交表单后跳转到另一个页面，这很适合写Selenium测试。这里关注的是另外一种， 即客户端页面逻辑，它与服务器没有交互，比如页面Dom元素的联动变化和数据校验逻辑等，这部分当然也可以写Selenium来测，而且由于不与服务器打 交道，组织得当的话速度也很快。但此时Selenium测试与代码实现的反馈距离太远，不方便组织细粒度的测试，更重要的是写这个测试对 Javascript代码的设计没什么帮助，因为再烂的Javascript实现可以方便地写出Selenium测试。

对于客户端页面逻辑，我们尝试使用Jsunit进行测试。对于没有Dom操作的纯Javascript函数，测试很容易。对于有一定复杂度并有Dom操作的逻辑，我们将他们封装成Javascript对象并用Jsunit测试它。

一个具体的例子

上图是页面的一部分......

Utility, Helper, Common常被用来给静态的工具类命名，我一看到这样的东西就不由地皱眉头，不是说工具类没有用，而是因为看到太多工具类的误用了。下面是我在工作中遇到的两个例子。

有一次，看到下面的Java代码：

public void doSomething(){
    if(StringUtil.isEmpty(this.value)){
        // do this way ...
    }
    else{
        // do that way ...
    }
}

代码使用了StringUtil，觉得奇怪，难道内建的String功能不够强大，还要搞出个StringUtil？直觉告诉我，isEmpty是多余的，一定是哪里做错了什么......

刚刚看了张五常老师的一篇博客，他通过一个浅显的例子，借助分析“借贷/资产比率”解释了次贷危机的原因，我总感觉不足以令人信服。

他的例子我总结了一下大致是这样的：

房价100万，按揭70万，此时“借贷/资产比率”是0.7，安全。如果放贷人拿着借据再向第三者借50万，市价100万的房子总借额是120万，“借贷/资产比率”是1.2，高于1，不安全。如果各方正常付息，则相安无事，但一旦房子所值不足，还款链条断裂，就麻烦了。这种按揭之上再按揭的做法，包括衍生品打包出售，会使得借贷比率升得很高，杠杆很大，最终形成危机。

这段描述有个问题：第一个放贷人......

修bug时我们都有这样的经历：简单查看了一下代码，发现没有那个类负责这个逻辑，进一步深入代码，查找一番，才在一个看似不相关的地方找到了错误的根源。原来这个逻辑被散落在几个地方，隐讳地错误实现了。我们在出错的地方多加一个if else，或是写点别的什么代码，这个bug就这样被fix了。

仅仅这样做虽然提高了软件的外部质量，但对内部质量的提高毫无益处，泄漏在外的逻辑不仅仍然无家可归，而且有变得越加复杂和晦涩的倾向。

每一个bug的出现都是对分析、设计和编码过程的一次质疑。这次......

Q:单元测试的主要作用有哪些?

A:单元测试的作用主要有：
   (1) 确保代码实现了预想的逻辑。这是所有测试都有的，也是最重要的功能。
   (2) 确保重构不破坏现有的功能。所有测试都或多或少地支持这一功能，有些“重构不友好”的测试在重构过程中可能会被删除或修改。
   (3) 驱动出设计，主要是帮助识别出类或接口函数。这是个一次性的好处，只有部分测试会起到这个作用。那些直接保证内部函数实现逻辑的测试起不到这个作用。
   (4) 当难以编写满意的测试时，提示开发人员现有设计的问题并鼓励他们重构现有的代码。这也是个一次性的好处，只有部分测试会起到这个作用。
   (5) 作为需求文......

    前些天在InfoQ中文站上发表了《软件开发中的准时化生产》一文，它是在我的一篇同名博文基础上修改而成的。李剑指出了原文中的很多问题，并给了我不少建议，新文章在内容、结构和语言上有了不少改进。

    文章简介：

• 在软件开发过程中进行频繁的交付，以此减少库存（部分完成的工作），暴露并消除浪费，加快价值的流动。
• 通过客户来拉动开发过程，确保每一时刻团队成员都在围绕客户认为最重要的软件功能展开工作。
• 在第一时间、第一现场发现问题，并从根本上解决问题，以此将质量内建在分析、设计和开发的过程中，而非依赖后期检测来保证质量。
• 将与项目相关的所有人组成高度授权的团队，通过可视化地向团队成员全面展示项目信息来支持自我决策。
• 当改进流程和实践时，要以快速交付和高质量为首要目标，而成本则要端到端地考量，低成本往往是实现快速交付与高质量的自然结果。

【本文发表于《程序员》杂志2008年第7期，是在《频繁的Switch Pair是一种浪 费吗？》一文的基础上修改而成的。】