问测试中的条件断言是反模式吗？

EN

您可以为整个组件的“烟雾测试”的目的将测试场景设置为条件，以表明在任何情况下，当您无法控制该情况以及哪一种变体将“出现”时，您都可以通过测试。

但是对于详细的测试，您应该记住，应该至少测试两种变体一次。

如果这是由测试数据或应用程序的任何其他外部选项或行为引起的，则没有具体说明是什么导致了变体。

如果它完全超出了您的控制范围，您应该在循环中对其进行测试，直到所有可用的变体都“通过”为止。如果您不这样做，它可以从某种角度被视为反模式，或者您应该将自动测试结果表示为部分结果。

您的示例(没有进一步的上下文)看起来更好，如下所示：

@Test
public void testStateA() {
    assertThat(system, shouldPerformInWay(X));
}

@Test
public void testStateB() {
    assertThat(system, shouldPerformInWay(Y));
}

它看起来像是两种不同的场景，所以请这样测试它们。如果您的原始代码失败(在方法shouldPerformInWay中)，您甚至不知道这两种情况中的哪一种失败--或者您必须提供额外的日志记录或调试。

当然，在使用数据驱动测试时，您必须在代码逻辑和数据可变性之间保持一定的平衡。

我不知道这是否适用于您的示例，如果没有代码，我的解释是否清晰，但是让我们假设我们正在测试登录屏幕。

极端一方面:复杂的数据(确定要遵循的逻辑)，复杂的代码。在这里，您可能有一个测试方法(简单)，并且基于数据，PageObject必须执行它的逻辑:检查是否有完整的登录或错误消息，或者.因此，您的代码(PageObject)是复杂的，因为它必须为预期的行为解析数据(例如:我的数据源是否提供了错误消息？)数据本身也必须提供预期的结果。

另一方面是极端:简单的数据，许多测试用例(针对每个结果)。在这里，您可能有许多测试方法(每个可能的场景都有一个)，每个测试方法都接受特定的数据输入。所以数据很简单，因为它不包含任何逻辑。测试方法可能是重复的，但对于它们所做的事情却很清楚。与前一种情况相比，PageObjects本身没有太多的逻辑，因为它们不必为行为解析数据。