我们正在使用SpecFlow进行功能测试,当人类读取生成的电子邮件并验证所有部分符合规范时,这些功能测试会取代手动测试。问题是,方案纲要成为成长有太多的参数如何解决具有太多参数的SpecFlow场景轮廓?
Scenario Outline: generate and send confirmation email
Given I have stored itinerary in '<EmbeddedItinerary>'
When Generate confirmation email
Then section1 should have parameters '<Param1_1>', '<Param1_2>', '<Param1_3>',...
Then section2 should have parameters '<Param2_1>', '<Param2_2>', '<Param2_3>',..
Then section3 should have parameters '<Param3_1>', '<Param3_2>', '<Param3_3>',...
....
例子:
| EmbeddedItinerary | Param1_1| Param1_2| Param1_3| Param2_1| Param2_2| Param2_3| Param3_1| Param3_2| Param3_3|...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
| Itinerary_1 | Value1_1 | Value1_2 | Value1_3 | Value2_1 | Value2_2 | Value2_3 |Value3_1 | Value3_2 | Value3_3 |...
但列的实例数量将变得难以管理。我希望有多行的例子(但是在Multiple Multi-Line Examples in SpecFlow Feature File中有不同的理由)。
我看到的选项是将所有ExpectedResults存储在嵌入式xml或json资源文件中,并且SpecFlow功能非常小,例如,
Scenario Outline: generate and send confirmation email with correct email address for flight section
Given I have stored embedded resource '<EmbeddedItinerary>'
When Generate confirmation email
Then sections should be as specified in '<ExpectedResultsFile>'
Examples:
| EmbeddedItinerary | ExpectedResultsFile
| Itinerary_1 | ExpectedResults1 |
| Itinerary_2 | ExpectedResults2 |
...
这是一个好主意吗?
任何人都可以提出更好的方式(更多SpecFlow风格)? 我担心的是将预期数据移动到单独的文件中我失去了可视性,这是SpecFlow功能的优势之一。
更新:在写这个问题时,我发现商业产品(每位用户$ AUD 255)Specflow + Excel http://www.specflow.org/plus/excel/getting-started/,这可能会满足我的需求来维护许多列。
它是一种成熟/可靠的产品吗?我应该使用它来代替自己解析专有格式的预期结果文件吗?
谢谢,安德烈亚斯,我的一位同事想要以同样的方式。我担心的是,实际的业务情景是发送包含所有部分的电子邮件,并确保所有部分都正确。你把它分解成单独的场景来单独测试每个部分的方法更像是单元测试,我们无论如何(但没有SpecFlow)。我错了吗? –
这取决于您对单元测试Unit的定义。通常它是一个类,所以你正在测试一个没有依赖关系的类的行为。如果超过这个参与自动化测试,你就开始称之为集成测试。当你正在生成文本和发送电子邮件时,我假设你在这里有不止一个班级。这意味着你有一个集成测试。 –
如何确定在同一测试中哪些值需要测试,取决于您的代码。如果您始终获得某个部分的相同内容,则无论您首先检查其他部分,如果您在一个场景或多个场景中检查它们,结果无关紧要。 但是,如果例如第2部分取决于您首先检查第1部分,然后您需要在一个场景中检查它们,因为如果将它们分开,则第1部分是较新的访问。 –