【问题标题】：Acceptance tests dealing with GUI?处理 GUI 的验收测试？
【发布时间】：2013-01-20 14:35:04
【问题描述】：

任何优秀的软件架构师都会同意，当某人从头开始构建一个新项目时，他一定不能在开始时就考虑边界（数据库、GUI、外部服务等...）事实上，他应该独立于任何后端构建他的软件核心，并将它们视为应用程序的一种“插件”。

TDD 和验收测试促进了每个新功能：

为功能编写失败的验收测试（端到端）
借助一些单元测试推动并完成您的代码设计
验收测试通过后立即完成。

但是，很多文章都解释说验收测试是一个真正的端到端测试，因此涉及 GUI（浏览器（例如使用 Selenium）或其他一些界面）。

验收测试不应该基于应用程序的 HEART 并且独立于任何边界吗？例如，它会迫使我考虑 GUI...：s

什么是好的做法？为每个功能编写两种验收测试？一种用于业务逻辑，另一种确保 GUI 正常工作？

【问题讨论】：

标签： unit-testing tdd continuous-integration bdd acceptance-testing

【解决方案1】：

首先让我建议阅读 Steve Freeman 和 Nat Pryce 的 Growing Object-Oriented Software, Guided by Tests。这是迄今为止我读过的最好的软件测试书籍。它的伟大之处在于作者不关注像Calculator 类这样的虚拟用例，而是使用TDD 来测试add(int, int) 方法。这很愚蠢。相反，他们使用 Swing 接口、通过 XMPP 的网络连接和相当多的业务逻辑来构建功能齐全的应用程序。这让我们回到您的问题。

上述书籍的作者使用了各种技术和工具，但他们始终坚持 TDD 实践。对于单元测试，他们选择mockito，但对于验收和集成测试，他们实际上是自动启动应用程序 (GUI) 和 XMPP 测试服务器。

他们设法通过在测试和 GUI 之间采用高度分离来测试驱动 GUI 测试。您应该将您的用户界面（Web、桌面、SOAP Web 服务等）隐藏在一个名为 driver 的抽象后面。您的测试仅使用像 placeOrder("Foo") 这样的高级方法与驱动程序交互。每个驱动程序（BrowserDriver、SwingDriver）都明白这意味着什么，要么浏览你的网页，要么点击胖 GUI 上的按钮。

如果您可以在不更改测试但仅通过更改底层驱动程序的情况下更改您的 GUI - 您做对了。

另见

Page Objects - 保持 Selenium 测试的可维护性
FitNesse

【讨论】：

谢谢托马斯！实际上，我拥有这本书，但还没有完成 :) 我喜欢你提到的“页面对象”的概念。总而言之，（在我重新打开本书之前）处理 GUI 的验收测试将定义一个通用的Driver（独立于任何特定的 GUI），并且这个可以由 Spring 注入，例如（webapp 的 selenium 驱动程序实例）。因此，我放弃了直接处理服务或实体的“低级”验收测试的想法，而是为一个功能定义了一个处理Driver 接口的唯一验收测试。有意义吗？
@Mik378;或多或少。你会得到SeleniumDriver implements Driver。这里不需要春天（尽管我很喜欢）。我相信这本书会比我更详细、更好地解释这一点。
我假设一个测试定义了一个 driver 字段并通过 Spring 由它自己的 application-context.xml 初始化。为什么是春天？因为它可以允许在我们添加另一种类型的 GUI => 只更改 Spring 的 xml 配置文件 (roger-almeida.blogspot.fr/2012/01/…) 的那一天保持测试不变。顺便说一句，感谢您的出色回答:)