Question

我有一个与验收测试驱动开发（ATDD）相关的问题。我的应用程序是作为REST服务开发的，可能有几个客户端 - 网站，移动，桌面。 ATDD概念说我应该通过端到端测试开始每个功能。由于我的服务可能有几个客户端应用程序（结束）提供相同的用例，我在编写验收测试时应该使用什么方法？验收测试是否应该将对REST服务或客户端应用程序的直接请求作为输入？或两者？我明白，如果我的验收测试从REST请求开始，我就省略了客户端部分，这绝对不行。如果这些从客户端开始，我将为每个客户端重复基本相同的功能测试。我需要找到一种方法，它位于这些边缘的中间位置。

Answer 1

在练习ATDD时，我认为验收测试只是另一个用户界面。话虽如此，我会在业务层的UI下面进行测试。假设我有一个功能：

Given I have an addend of 5
and an augend of 3
When I calculate the sum
Then I should receive 8

实施此测试时，我的接缝将位于业务层。假设一个Java / Spring类型的应用程序，我的测试看起来像：

@Given("I have an addend of (\\d+)")
public void addend(int addend) { this.addend = addend; }

@Given("I have an augend of (\\d+)")
public void augend(int augend) { this.augend = augend; }

@When("I calculate the sum")
public void calculate() {
    calculator = applicationContext.getBean(ScientificCalculator.class);
    actualResult = calculator.sum(addend, augend);
}

@Then("I should receive (\\d+)")
public void verifyResult(int result) { assertEquals(result, this.actualResult); }

一旦我开发了ScientificCalculator背后的业务逻辑并且所有测试场景都通过了，我就知道应用程序从功能角度做了它需要做的事情。因为这完全绕过了UI，所以不需要为每个UI复制测试。用户界面现在完全没有业务规则（这是一件好事），您可以将XML，JSON，HTML，无论您想要的UI放在前面。假设我们使用的是Spring MVC，那么控制器就像下面这样简单：

@GET("calculate/sum/{addend}/{augend}")
public void addSomeNumbers(String addend, String augend) {
    result = calculator.sum(Integer.parseInt(addend), Integer.parseInt(augend));
    // Render the view with the result.
}

我会测试用户界面吗？大概。但是并不是那么彻底，因为现有测试涵盖了主要的业务规则，一般来说，UI漏洞的风险比错误或错误实现的业务逻辑更容易解决。

希望有所帮助！

布兰登

Answer 2

正如@bcarlso建议的那样，您可以根据业务规则编写验收测试，因此它们不是针对某个特定平台的。

使用这些规范在每个平台上端到端地测试每个场景当然是可能的，并且许多组织都这样做。但是你很可能以一个非常庞大，缓慢的测试套件结束，这将难以维护。

黄瓜和类似工具ATDD并未强制要求您进行端到端测试。您可以使用它们来验证在一个类中作为单个方法关注的事物中的行为。

集中精力编写良好的单元测试，以便在集成之前捕获绝大多数缺陷。不要依靠自动验收测试作为糟糕开发过程的QA。使用少量高级端到端测试来测试应用程序的主要成功路径。

这里有一个权衡：一些与整合相关的问题可能会漏网。执行根本原因分析并尝试确定将来如何避免类似的缺陷。在适当的级别添加其他测试。只是不要让你的项目淹没在自己的测试套件中。

验收测试驱动多个客户的服务开发

2 个答案: