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

Question

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

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

• 为后端编写测试，然后为前端编写更多的Javascript测试

我是不是该：

• 将测试编写为Selenium宏，以模拟实际浏览器中的鼠标单击等？

我这样做的好处是：

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

有什么想法吗？

Answer 1

我们已经为使用WPF测试工具（ WipFlash ）的C＃应用​​程序完成了此任务，并以类似BDD的方式编写了NUnit测试。

例如

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

不用说，我们必须自己编写许多DSL代码。 但是，它变成了业务/客户可读的解决方案。

Answer 2

尝试将SpecFlow与WatiN结合使用：（我不确定您是否在这里使用.NET）

http://msdn.microsoft.com/zh-CN/magazine/gg490346.aspx

Answer 3

对于Web测试，您可以尝试WebDriver。 Selenium团队目前正在忙于集成WebDriver。 创建WebDriver的Google的Simon Stewart 在这里写了一篇关于它与Selenium的不同之处的博客 。

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

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

Answer 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和用于测试的自定义语言。 它不仅限于Web，还包括Email，FTP等。上面的示例语言是TestPlan片段。

Answer 5

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

RSpec书提倡两级循环，首先编写验收测试（或方案）（主要在Cucumber中 ），而在内部循环中编写的单元测试（以RSpec编写）则更类似于传统的TDD。

验收测试的外部周期也可以使用Selenium之类的工具来通过UI驱动整个应用程序（《 RSpec书》的作者为此花了一章）。 但这不适用于单元测试。

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

Answer 6

实际上，您可以两者兼而有之-创建一个以用户为中心的Driver界面（与GUI / tech / impl无关）。 然后，您可以编写UIDriver和AP​​IDriver并选择一个驱动程序以运行特定的测试。 通过UI运行通常会比较慢（在proc之外，控件会重新绘制，但最初会以某种方式创建更高的置信度）。 通过API运行要快得多（在过程中，易于进行安装拆卸）。

这里的技巧是将“方法”与“方法”分开。 否则，您将获得ObscureTests和高测试维护。 确保主要关注测试而不是自动化。