使用 UI 驱动程序进行 BDD 测试（例如，用于 Web 应用程序的 Selenium）答案

【问题标题】：BDD-testing using a UI driver (e.g. Selenium for a web-application)使用 UI 驱动程序进行 BDD 测试（例如，用于 Web 应用程序的 Selenium）
【发布时间】：2011-01-03 12:00:44
【问题描述】：

可以使用 UI 驱动程序实现 BDD（行为驱动设计）测试吗？

例如，给定一个 Web 应用程序，而不是：

为后端编写测试，然后在前端用 Javascript 进行更多测试

我应该：

将测试编写为 Selenium 宏，在实际浏览器中模拟鼠标点击等？

我看到这样做的好处是：

测试是用一种语言编写的，而不是多种语言
他们专注于 UI，这让开发人员能够由外而内地思考
它们在真实的执行环境（浏览器）中运行，这使我们能够
- 测试不同的浏览器
- 测试不同的服务器
- 深入了解实际性能

想法？

【问题讨论】：

标签： tdd bdd web-testing

【解决方案1】：

我们使用 WPF 测试工具 (WipFlash) 为 C# 应用程序完成了这项工作，并以类似 BDD 的方式编写 NUnit 测试。

例如

Given.TheApplicationWindowIsOpen();
When.I.Press.OKButton();
The.Price.ShouldBeCalculated();

不用说，我们不得不自己编写大量的 DSL。但它变成了业务/客户可读的解决方案。

【讨论】：

喜欢你所使用的语法。使用业务术语来避免转向单元测试似乎非常重要。

【解决方案2】：

尝试将 SpecFlow 与 WatiN 一起使用：（我不确定您是否在此处使用 .NET）

http://msdn.microsoft.com/en-us/magazine/gg490346.aspx

【讨论】：

好主意。我实际上已经在考虑这一点，但后来又重新考虑了，因为 Watin 缺乏对最流行的 3 浏览器引擎的完全支持。但是，既然您提到了 SpecFlow，我认为这个优势让 Watin 看起来是一个更好的选择！

【解决方案3】：

对于网络测试，您可以尝试 WebDriver。 Selenium 团队目前正忙于集成 WebDriver。来自 Google 的 Simon Stewart，他创建了 WebDriver，blogged here about how it works differently 到 Selenium。

WebDriver 为每个浏览器使用不同的技术。对于 Internet Explorer，WebDriver 使用 Microsoft 的 UI 自动化——@Brian Agnew 提到的WipFlash 所基于的技术相同。这与您假装单击按钮一样接近。 Simon 的博客展示了为什么这种方法比 Selenium 的 Javascript 解决方案更强大。

WebDriver 可从 Selenium 站点获得，但尚未作为 Selenium 的一部分完全实现。

【讨论】：

【解决方案4】：

对于 BDD 和任何用例驱动的测试，能够传达测试正在做什么很重要。许多测试套件的问题在于，编写后没有人完全确定测试在做什么。如果您使用非专业语言写作，这将经常出现。专业化并不一定意味着一种特殊的语言，只是一种语言的抽象就足够了，所以很清楚正在发生什么。

例如，很多测试都有这样的代码（伪代码，我不会选择任何特定的框架）：

object = createBrowser()
response = object.gotoURL( "http://someurl.com" );
element = response.getLink( "Click Here" );
response = element.doClick();

这对于某些人来说很难快速转化为业务驱动力（可能是产品经理或用户）。相反，您想创建专门的函数，或者如果您喜欢冒险，您可以创建一种语言，因此您可以拥有这个：

GotoURL http://someurl.com/
Click link:Click Here

Selenium 及其宏或接口在这方面仍然相当低级。如果您确实使用它们，那么至少在它们周围构建一些包装器。

您当然也可以使用名为TestPlan 的产品。它在后端有 Selenium，并公开了一个高级 API 和一个用于测试的自定义语言。它不仅限于网络，还包括电子邮件、FTP 等。上面的示例语言是 TestPlan sn-p

【讨论】：

【解决方案5】：

您当然可以通过这种方式进行一些验收测试，但我认为大多数 BDD 倡导者不会建议在所有测试中都使用这种方式。当然，真正的 BDD 拥护者不会称它们为测试......

The RSpec Book 提倡两级循环，首先编写验收测试（或场景）（主要在 Cucumber 中），然后在更类似于传统 TDD 的内部循环中编写单元测试（在 RSpec 中）。

验收测试的外部循环也可以使用像 Selenium 这样的工具来通过 UI 驱动整个应用程序（RSpec Book 的作者在这方面花了一章的时间）。但它不适合单元测试。

通过 UI 执行整个应用程序的测试更难重复，并且比单元测试更慢且更脆弱。

【讨论】：

RSpec 和 cucumber 用于 Ruby。如果您使用的是 .net，则可以使用类似于 cucumber 的 SpecFlow。

【解决方案6】：

实际上，您可以两者兼得 - 制作以用户为中心的驱动程序界面（与 GUI / tech / impl 无关）。然后您可以编写一个 UIDriver 和一个 APIDriver 并选择一个驱动程序来运行特定的测试。通过 UI 运行通常较慢（超出过程，控制重绘，但最初以某种方式创建了更高的置信度）。通过 API 运行要快得多（在 proc 中，简单的 setup-teardown）。

这里的诀窍是将 What 与 How 分开。否则，您最终会遇到 ObscureTests 和高测试维护。确保主要关注测试而不是自动化。

【讨论】：