问在自动化测试中应该有任何业务逻辑吗？

EN

我同意在测试中重新实现SUT算法是个坏主意。这很糟糕，因为测试的算法和SUT的算法一样容易出错。或者更糟的是，测试可能会在SUT中复制一个bug。

如果您的测试硬编码了预期的结果，而不是计算预期的结果，它可能需要包含更多的注释来解释结果的来源。

你的测试应该有尽可能少的逻辑。这有助于防止测试中的额外错误，这可能导致假阳性/假阴性。硬编码您的预期结果是一种可接受的方法。您不应该在测试中重新实现您的特性。

我们应该在测试中复制业务逻辑吗？

不是的。

理想情况下，一旦软件完成了测试，那么测试就应该使用预期的预先确定的SUT状态来断言实际的状态。

就计算预先确定的预期状态而言，测试的主要目的是“验证”预期状态，而不是“复制”它。

在我们的团队中，它是直接在测试中硬编码的，从以BDD( Cucumber)格式捕获的使用故事中复制，作为一个示例场景，数据充当业务分析师、开发人员和测试人员之间的通信工具。

但是，除了测试前后的测试数据设置/清理之外，在测试之间没有场景操作，比如DB操作/ API调用。没有在测试中重新计算业务逻辑。一个很大的不。

如果我们这样做，那么我们也需要对这些测试进行测试，因为它们不再是测试，因为它们自己实现了与应用程序代码相同的功能。