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

Question

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

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

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

我应该：

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

我认为这样做的优点是：

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

有想法吗？

Answer 1

我们使用 WPF 测试工具 (WipFlash) 并编写 NUnit 对 C# 应用程序完成了此操作以类似 BDD 的方式进行测试。

例如

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

，不用说，我们必须自己编写大量 DSL 代码。但它成为企业/客户可读的解决方案。

Answer 2

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

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

Answer 3

对于 Web 测试，您可以尝试 WebDriver。 Selenium 团队目前正忙于集成 WebDriver。来自 Google 的 Simon Stewart 创建了 WebDriver，在博客中介绍了 WebDriver 的不同工作方式< /a> 到硒。

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 和用于测试的自定义语言。它还不仅仅限于网络，还包括电子邮件、FTP 等。上面的示例语言是一个测试计划片段

Answer 5

如果这对某人有帮助，我为此目的编写了一个驱动程序构建器库：
https://github.com/morsh/driver-pattern

BDD 壮举。司机及构建器模式

使您能够像这样编写驱动程序：

describe("<ToDoList />", () => {
  const driver = createDriver(Component, {
    getters: {
      todoItems: 'todo-item',
      addButton: 'add-button',
      todoTitle: (index: number) => screen.queryAllByTestId('todo-item')[index],
      deleteButton: (index: number) => screen.queryAllByTestId('delete-button')[index],
    },
    actions: get => ({
      clickAdd: () => fireEvent.click(get.addButton()),
      clickDelete: (index: number) => fireEvent.click(get.deleteButton(index)),
    }),
    createStore,
  });

  beforeEach(() => {
    drive.initialize()
  });

  it("should display list of todo items", () => {
    const todos = someTodoItems();
    driver.givenState.todos(todos).when.render();
    expect(driver.get.todoItems()).toHaveLength(todos.length);
  });

  it("should click on add", () => {
    const onClickSpy = jest.fn();
    driver.given.onClick(onClickSpy).when.render();
    expect(onClickSpy).toHaveBeenCalled();
  });
});

Answer 6

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

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

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

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

Answer 7

实际上，您可以两者兼得 - 制作一个以用户为中心的驱动程序界面（与 GUI / 技术 / impl 无关）。然后，您可以编写 UIDriver 和 APIDriver 并选择一个驱动程序来运行特定测试。通过 UI 运行通常会比较慢（在进程之外，控件会重新绘制，但以某种方式最初会创建更高级别的置信度）。通过 API 运行速度要快得多（在过程中，轻松设置-拆卸）。

这里的技巧是将“什么”与“如何”分开。否则你最终会遇到 ObscureTests 和高测试维护。确保主要关注测试而不是自动化。