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

核心提示：在过去的十年里，使用自动化单元测试套件的做法已经被广泛接受，FlexMonkey将单元测试引入Flex用户界面开发，以至于当前大多数开发人员都会从事一定数量测试代码的编写，或者至少会感觉不写不好，开发人员必须为应用程序提供一系列自上而下并且端到端（前端到后端）的测试，另外有证据表明即使自动化测试少到只覆盖50%的代码，

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

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

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