【问题标题】:Iterate Scenario Steps using SpecFlow使用 SpecFlow 迭代场景步骤
【发布时间】:2013-09-30 08:49:18
【问题描述】:

我正在使用 SpecFlow 来 BDD 我的应用程序。 我想迭代测试,而每次迭代都重复之前分配的参数。

由于这一步应该执行大约 120 次,我不想用不同的参数重写相同的测试。

是否可以只迭代场景部分?

真实场景:

我有打开文件然后关闭它的应用程序功能。

我想打开和关闭文件,直到应用程序失败。

我制作的最后一个测试套件(使用纯 C# 代码)在被测应用程序中发现内存泄漏导致第 10 次迭代失败,但在调试被测应用程序后,它在 50 多次迭代时仍然失败(再次由于内存泄漏)。

我想使用规范流来测试这个场景。

出于日志记录的原因,我想将每个迭代拆分为不同的场景。 所以不是编写包含许多子场景的特征文件,有没有办法告诉 SpecFlow 以升序重复序列进行迭代?

场景:

Scenario Outline: Open and close fileTestScenario1
Given Ready for input
When Open file <file_name>
Then File content is visible

Examples:
    | file_name | 
    | param1   | 
    | param2   | 
    | param3   | 

所以我希望 SpecFlow 生成以下测试:

  1. 使用 param1 调用场景(使用 param1 和断言调用)
  2. 使用 param1 和 param2 调用场景(使用 param1 调用并断言,然后使用 param2 和断言调用)
  3. 使用 param1 和 param2 和 param3 调用场景(使用 param1 调用并断言,然后使用 param2 调用并断言,然后使用 param3 和断言调用)
  4. ...

我知道这个场景是原子测试单元,但是,如果我想执行这个任务 - 怎么做?

【问题讨论】:

  • 也许您可以详细说明您的问题。我不确定我是否解决了您的问题。但是我认为你的问题是,它不能使用 SpecFlow 来完成。因为您正在寻找的功能非常简单而且并不复杂,所以我认为最简单的方法是将其编码在您的“当我以 身份登录时”后面的代码中。
  • @TimothyHeyden 上面的例子简化了问题。我想一遍又一遍地用不同的参数迭代步骤,不要重复我的代码
  • 这似乎是一个很奇怪的要求。如果我没看错,你想要:测试 1 = 动作 A,断言 a;测试 2 = 动作 A、断言 a、动作 B、断言 b;测试 3 = 测试 2 + 动作 C,断言 c。你为什么要这个?您是否试图找出在一系列步骤中发生故障的位置?您能否使用更多“真实世界”类型的示例并解释为什么需要这种断言/测试运行模式?
  • “在我进行的最后一次测试中(使用纯 C# 代码),由于内存泄漏,我在第 10 次迭代中失败了。”-正如您使用单元测试确定了内存泄漏问题,我会继续使用单元测试来解决这个问题。此外,SpecFlow 测试应该是明确的并表达预期的输入和输出。 “然后测试通过”太含糊了,将其替换为“然后我可以看到文件内容”或类似内容。此外,“示例”应该记录用户应该期望的内容,让代码合并“示例”块中的结果会让读者感到非常困惑。
  • @Fresh 我接受您的评论 - 但除非我解释被测应用程序和测试的整个逻辑,否则我的要求可能不清楚。但我不寻找解决方法或建议以技术方式解决此问题,只是想知道是否可以使用 SpecFlow 迭代部分场景?

标签: unit-testing bdd specflow


【解决方案1】:

如果您只是将测试表述为

Scenario Outline: Open and close fileTestScenario1
Given Ready for input
When Open file <file_name>
Then File content is visible

Examples:
| file_name | 
| param1    | 
| param1,param2   | 
| param1,param2,param3   | 

有绑定

[When("Open file (\w+)"]
public void WhenOpenFiles(string names)
{
  foreach(var name in string.Split(',', names)
  {
       OpenFile(name);
  }
}

但是,这种方法(称为详尽测试)并不是进行测试的最佳方法。在这种情况下,您在运行大量测试以希望遇到问题时所做的一切。至少减少测试,而不是运行 1 个文件,然后是 2 个文件,然后是 3 个等,而是直接跳到 50 个文件,因为这也可以处理更简单的情况。您还应该使用这种方法来简单地诊断真正的问题是什么,然后编写一个有针对性的测试来直接解决该问题。

例如,我今天遇到了一个失败的现有测试,它失败只是因为它是星期一,即它有一些日期逻辑,只有在星期一发生的一些 TimeSpans 重叠期间才会失败.但是我通过写一个详尽的测试证明了这一点,

Foreach(var day in new[] { DayOfWeek.Monday, DayOfWeek.Tuesday, ....}
   Foreach(var hour in Enumerable.Range(0, 24)
     Console.Writeline(test(day, hour));

然后我删除了详尽的进近测试,因为我只能在星期一上午 10 点用一次测试替换它。

希望这会有所帮助。

【讨论】:

  • 感谢您的回复。这是一个非常有效的解决方法,但正如我之前提到的,如果 SpecFlow 支持请求的场景,我想得到是或否的答案。
  • 最后一件事 - 请接受关于单词选择的评论 - 在术语“shotgun”中的使用(作为偶尔使用的术语“cannon”、“war room”、“battle zone”等)是错的。霰弹枪这个词(以及我提到的其他词)与高水平的攻击性、生命威胁、痛苦和消极状态有关。我发现使用这种术语阅读(任何)文本令人不快。我没有使用私人消息发送此评论,因为我认为需要听到这些话。感谢您聆听(甚至不接受)我的评论
  • 谢谢,看来我没有使用正确的术语,所以我在上面更新了。
猜你喜欢
  • 2016-02-13
  • 1970-01-01
  • 2015-07-25
  • 2017-03-28
  • 1970-01-01
  • 2016-02-04
  • 1970-01-01
  • 2017-08-20
  • 1970-01-01
相关资源
最近更新 更多