Specflow - “场景"之间的状态 [英] Specflow - State between "scenarios"

问题描述

使用 Specflow，我正在编写一套场景来模拟每月的工资单，验证每个月的计算付款以及最后的年终数据.

Using Specflow, I'm writing a suite of scenarios that model monthly payrolls, validating the calculated payments for each month and finally the yearend figures.

每个月的结果都是累积的，所以后面的每个场景都依赖于上个月的加减.支付计算通过第三方工具写入数据库，因此在场景之间创建和销毁测试数据的成本很高.

The result of each month is cumulative, so each subsequent scenario is dependent on the previous month’s additions and deductions. The payment calculations are written to a database via a third party tool, so creating and destroying test data between scenarios is expensive.

根据我的测试经验，我知道并非总是可以确保测试的执行顺序.我可以通过一些场景命名约定来控制执行顺序，但不能保证远程测试运行器会按字母顺序运行测试.

From my experience with testing, I know it's not always possible to ensure the execution sequence of the tests. I can control the sequence of execution with some scenario naming conventions, but can't guarantee that a remote test runner is going to run tests in alphabetical order.

我考虑过的选项:

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

• Run the entire year through a single scenario including lots of given, when, then assertions. This results in a single huge scenario that is difficult to read.
• Create a concatenation "Given" for each scenario. "Given: All payments to month X have been made". This creates lots of database traffic as each scenario will need to create and destroy test data.

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

Is there a better way to store state between scenarios and ensure scenarios are executed in the desired sequence?

推荐答案

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

Relying on the order of execution of the scenarios is an anti-pattern and should be avoided. Test runners usually don't provide any mechanism to control the order of execution for the same reason. It would be also against the concept of executable specification: the scenario should be understandable (and executable) on its own.

在您的情况下， Given 部分应为所讨论的计算准备数据，When 应计算， Then 应检查该单个计算的结果.

In your case the Given part should prepare the data for the calculation in question, the When should calculate and the Then should check the result of that single calculation.

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

To reduce the execution time maybe you could try to select "important" scenarios in a way that they test different aspects. Probably it is not necessary to test each month 1-11. You could have one test for the first monthly payroll, one for the 2th month, one to close an entire year, one to start a new year, etc.

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

It is also a common technique that the Given must not necessarily be done the same way as the "real application" would do (from scratch). Sometimes you can do shortcuts in the test to ensure the prerequisites in a faster and easier way. E.g. you could specify the sums of the previous month if that's all your scenario needs to calculate the next month (instead of letting the app calculate everything from scratch). Of course you have to know what you are doing and you have to consider the risk involved with faking some aspects of the application.

这篇关于Specflow - “场景"之间的状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！