FlexMonkey将单元测试引入Flex用户界面开发

FlexMonkey将单元测试引入Flex用户界面开发2011-04-10 infoq 译:曹如进在过去的十年里，使用自动化单元测试套件的做法已经被广泛接受，以至于当前大多数开发人员都会从事一定数量测试代码的编写，或者至少会感觉不写不好。然而自动化单元测试的不断使用却带来了一些混乱，即谁该测试什么。开发人员是否需要在所有的代码中覆盖单元测试，如果这样做了，是不是意味着我们就不再需要专门的QA测试人员了？许多开发团队在用户界面这块划了界线，他们认为用户界面需要很少的编码或者根本不需要编码，因此可以更经济地让专门的测试人员手工或是使用专门的测试工具进行测试。这种分工倾向于将测试划分成“单元测试”和“功能测试”，由开发人员负责前者，而由QA测试人员负责后者。本文将探讨 Gorilla Logic公司的全新开源Flex用户界面自动化测试工具FlexMonkey，看看它是如何提高开发人员和QA测试人员生产力的。FlexMonkey允许开发者将用户界面测试纳入到单元测试套件和持续集成环境中，还允许QA测试人员将那些测试扩展到综合质量测试中。

虽然开发人员和QA测试人员的最终目标都是确保应用程序正常工作，但是开发人员测试的首要目标和QA还是有所不同的。开发人员测试的目标是为了保证新编写或者修改的代码能够如愿工作而不导致“回归”（也就是说，无意中破坏了之前工作的代码）。自动化回归测试是敏捷开发中至关重要的一个部分，因为只有疯了的开发人员才会在大量琐碎的代码重构后，不用足够的自动化测试去确保重构后的代码仍然工作。

我们有理由期待开发人员去测试每一个新编写的代码片段，但是将每一个这样的测试实行自动化则是不必要的。手工测试对于新的或是修改的功能而言非常高效，但对于防止回归而言又总是不切实际。为了防止回归，开发人员必须为应用程序提供一系列自上而下并且端到端（前端到后端）的测试，另外有证据表明即使自动化测试少到只覆盖50%的代码，它也能在很多应用中有效的防止回归。

QA测试比起开发人员的测试要来的更加细致，因为它的目标是确保代码能够在任何可以想到的使用场景中正常工作。换句话说，QA测试人员的任务就是通过在应用程序上做一些可怕的事情来破坏它。当然开发人员肯定很熟悉这些所谓可怕的事情并且他们自己就可以做这方面的测试，但是这样做会使得他们真正写代码的时间变得很少。

一个合格的开发人员在测试时要么采用测试优先准则，即在API本身被实现之前就创建好测试它的少量测试用例，要么采用写一点，测一点（code- a- little-test-a-little, CALTAL）的准则，即每一个开发出来的代码单元在编译完后都会马上测试。CALTAL方法在用户界面（UI）开发人员中尤其流行，但是不同于API的在实现之前就能定义好逻辑接口的是： CALTAL在没有实际实现界面和控制代码前，并没有很好的方法来表达如何测试用户界面。

程序员们一般都主要依靠xUnit家族的测试框架来组织和执行单元测试。xUnit框架，例如 Junit和FlexUnit，可以帮助开发人员管理大量的自动化测试套件。利用这些框架，单个测试套件可以单独的或是组合的运行，就是说为系统的某个部分开发的测试套件既可以独立运行，也可以作为测试完整系统或整个应用中更大测试套件中的一部分来运行。此外，框架提供的综合报告使得开发人员和管理人员可以轻松的查看汇总和详细的测试结果。xUnit测试是本身就可以执行应用程序代码，并且检查实际结果和期望结果是否一致的小程序。xUnit测试套件提供了一个简便并且高效的方法来防止回归。大多数的生成系统，如ant，为应用程序生成过程运行将xUnit测试套件提供了直接的支持。而持续集成系统，如Cruise Control或Hudson ，在每一次代码提交到团队的版本控制系统后都会自动的触发这些编译，并且帮助检查团队中是否有人应该被笑话提交了不能通过测试套件的代码（这些笑话对于提高开发团队的总体效率是至关重要的）。