单元测试是保证软件开发质量的一个重要部分，对于敏捷和极限编程开发方法尤其如此。通常，对 Web 2.0 客户端用户界面进行自动的单元测试很困难，所以很少有人去做尝试。然而，Dojo 提供了一个单元测试工具，借此可以评估 JavaScript 的功能及用户界面的可视性。经过这个工具彻底测试过的用户界面最终包含的 Bug 数量会极大的减少。本文阐述了 Dojo Objective Harness (DOH) 的主要特点并通过与其它 Web 2.0 应用程序测试工具的比较展示了其强大的功能。
编写单元测试通常是为了测试一段源代码。理论上讲，这个代码片段（或者说是代码单元）是源代码中最小的可测试部分。一个单元测试通常是自动进行的，但也不一定必须自动执行，单元测试的结果表明这段代码是否能按照设计的要求工作。
众所周知，软件开发人员在时间方面通常都很紧张。为了将产品尽快投入市场，他们要面临不小的压力，那么为什么还要在编写单元测试上花费更多时间呢？这是因为一个充分的单元测试套件不仅能产生高质量的代码，并且由于减少了调试 Bug 的时间而最终节省大量时间。另外，如果能依照敏捷开发方法在编写源代码前先编写单元测试，还会减少所需编写的代码。如果在开始编写代码前先对设计进行全面细致的考虑，也能减少您为实现单元测试的目的而需要编写的代码量。
|
单元测试有众多的支持者，正如在极限编程以及敏捷编程中看到的那样。Asynchronous JavaScript + XML (Ajax) 及 Web 2.0 用户界面的广泛使用催生了对客户端单元测试的需求。Dojo Objective Harness 是 Web 2.0 UI 开发人员用于 JUnit 的工具。与已有的 JavaScript 单元测试框架（比如 JSUnit）不同，DOH 不仅能够实现在使用或不使用 Dojo 的情况下自动处理 JavaScript 函数，它还可以对用户界面的可视性 进行单元测试。这是因为 DOH（多好的缩写名）既提供了命令行界面，也提供了基于浏览器的界面来测试框架。
|
前面提到过，DOH 既提供命令行界面，又提供了基于浏览器的界面。如果单元测试需要完全自动化，并且不需要可视组件，那么命令行界面是个不错的选择，这是因为它可通过一个构建脚本启动，且其结果可被记录。此外，这个界面还提供了一个与 JUnit 非常相似的单元测试环境。DOH 为其命令行界面还使用了 Rhino，一个用 Java™ 代码编写的开源 JavaScript 引擎。正因如此，对 document、window、DOMParser 和 XMLHttpRequest 对象的引用无法被解析。Rhino 的另一个问题是它使用了一个与一般浏览器不同的 JavaScript 解释程序，这使得测试有可能在一个运行时内通过，而在另一个运行时内则不能。
如果单元测试需要可视组件和访问各种 JavaScript 对象，那么基于浏览器的界面将是最佳选择。需要提醒您的是使用浏览器的单元测试并不是 100% 自动的；您必须在自己衷爱的浏览器中启动单元测试并要检查其结果。其实这并不意外。一个 UI 外观的好坏通常是人的主观判断。浏览器测试的运行程序提供了两个途径来显示测试结果：一个是可视化结果，另一个是单元测试统计数据。图 1 在左侧显示了运行的测试用例，而在右侧 Test Page 选项卡下则可视化显示了代码执行（单击 这里 可以看到图 1 的放大图）。
图 1. DOH 单元测试可视化
图 2 显示了在 Log 选项卡下的单元测试统计数据（单击 这里 可以看到图 2 的放大图）。
图 2. DOH 单元测试统计数据
本文转自IBM Developerworks中国
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。