单元测试为黄瓜验收测试

Question

我们已经测试了我们的应用程序单元，并且使用Robot验证基本功能有两个系统测试。我们使用Cucumber运行Gherkin中的.feature文件也有很多要求（验收测试）。

我们开始使用放心实现它们作为集成测试 - 一切都很好用于基本功能。问题在于实现更详细的方案 - 我们需要验证的一些事情不会保留在DB中或由端点返回。

通过将这些场景作为单元测试来测试该功能真的很容易，但我不确定这是不是一个好的做法？

Answer 1

我认为需要在自己和业务之间来回徘徊。您通常最终会进行一些集成测试以证明该功能在快乐路径/负面情况下端到端地工作，但您不会经历所有边缘情况，因为这样做成本很高（耗时，特别是在运行集成测试时）。这就是单元测试的内容，涵盖了每个场景。传达给企业，他们可能学会信任你的判断，而不是将每一个验收标准作为集成测试来实现。

Answer 2

我将您的问题解释为“在使用BDD的同时使用单元测试是否可以？”

我的看法是这两种技术相互补充。如果使用一种技术更容易，那么在特定情况下使用该技术。

使用支持您提供工作软件的任何内容。工作软件是目标，而不是使用特定工具。

Answer 3

  

通过将这些场景作为单元测试来测试该功能真的很容易，但我不确定这是不是一个好的做法？

如果它们没有实施，那么尽快做到这一点绝对是一种好习惯，但是，我要注意测试的范围。我也发现使用Cucumber来帮助你进行单元测试没有问题，但是不要让你的单元测试更大范围验收测试。尽可能保持直接。

你提到了其中一些场景的复杂性：

  

我们需要验证的一些事情不会在DB中保留或由端点返回

然后代码应该在不同级别上更可测试/可维护。您可以通过一些技术实现这一目标。根据您使用的语言，您可以使用类似于mockito spy的工具来监视对象的交互，否则您无法检查，但是，这样做是明智的。适当的测试范围，例如Unit和Mock测试。

另外，如果您使用不同的测试级别覆盖给定流的不同部分，请考虑它是完全正常的。理想情况下，您将通过单元测试覆盖大部分内容。

您可以通过单元测试保留最复杂的单元部件，并且仍然保持更高级别的接受方案业务要求您，但不要在测试中做深度断言。