Specflow - “场景”之间的状态

Cr1*_*spy 4 testing uat specflow

我正在使用 Specflow 编写一套场景,对每月工资单进行建模,验证每月计算的付款以及最终的年终数据。

\n\n

每个月的结果都是累加的,因此后续的每个场景都依赖于上个月\xe2\x80\x99s的加减。支付计算通过第三方工具写入数据库,因此在场景之间创建和销毁测试数据的成本很高。

\n\n

根据我的测试经验,我知道并不总是能够确保测试的执行顺序。我可以使用某些场景命名约定来控制执行顺序,但不能保证远程测试运行程序将按字母顺序运行测试。

\n\n

我考虑过的选项:

\n\n
    \n
  • 通过一个单一场景来运行全年,其中包括大量给定、何时、然后的断言。这导致了一个难以阅读的巨大场景。
  • \n
  • 为每个场景创建一个串联“Given”。“已知:X 月的所有付款均已支付”。这会产生大量数据库流量,因为每个场景都需要创建和销毁测试数据。
  • \n
\n\n

是否有更好的方法来存储场景之间的状态并确保场景按所需顺序执行?

\n

Tz_*_*Tz_ 5

依赖场景的执行顺序是一种反模式,应该避免。出于同样的原因,测试运行程序通常不提供任何机制来控制执行顺序。这也违背了可执行规范的概念:场景本身应该是可理解的(并且可执行的)。

在您的情况下,给定部分应该为相关计算准备数据,何时应该计算,然后应该检查该单个计算的结果。

为了减少执行时间,也许您可​​以尝试以测试不同方面的方式选择“重要”场景。可能没有必要每个月1-11都测试。您可以对第一个月工资单进行一次测试,对第二个月进行一次测试,对一整年进行一次测试,对新的一年进行一次测试,等等。

这也是一种常见的技术,即给定不一定以与“实际应用程序”相同的方式完成(从头开始)。有时你可以在测试中走捷径,以更快、更简单的方式确保满足先决条件。例如,如果您的场景需要计算下个月的所有内容,您可以指定上个月的总和(而不是让应用程序从头开始计算所有内容)。当然,您必须知道自己在做什么,并且必须考虑伪造应用程序某些方面所涉及的风险。