验收测试驱动开发的服务与几个客户端

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

来源

2013-03-27 Markus

“ATDD概念，说我应该开始每一项功能与终端到终端的测试”。我不同意这是必需的。你的来源是什么？ – 2013-03-30 02:34:25

在练习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 /弹簧类型的应用程序：

@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吗？大概。但还不够彻底，因为现有测试涵盖了主要业务规则，而且一般来说，UI错误的风险要低于误解或错误实施的业务逻辑，因此风险要低一些，并且易于修复。

希望有帮助！

布兰登

来源

2013-03-28 00:17:53 bcarlso

由于@bcarlso建议，可以在业务规则方面编写验收测试，所以他们不是具体到某个特定的平台。

使用这些规范来测试每个平台的端到端情况当然是可能的，许多组织都这样做。但是你可能会以一个非常大的，速度很慢的测试套件结束，这很难维护。

黄瓜和类似工具ATDD并没有要求您测试端到端。您可以使用它们来验证在某个类中作为单一方法聚焦的某些内容中的行为。

重点关注您的努力，撰写良好的单元测试，以便在集成之前捕获绝大多数缺陷。不要依靠自动化的验收测试来作为一个糟糕的开发过程的质量保证。使用少量的高级端到端测试来测试通过应用程序的主要成功路径。

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

来源

2013-03-30 02:47:37

验收测试驱动开发的服务与几个客户端

回答

相关问题