Gherkin 场景的灵活性。
Flexibility of scenarios in Gherkin.
我正在寻找可以构建更灵活场景的机制。
例如,对于测试数据库中记录是否存在的这两个非常相似的场景:
Scenario Outline: Testing query with 1 attribute with these 2 record in and another 2 out of result
Given I'm connected to <db> database
When I select <query> from database
Then Result should contain fields:
| <row> |
| <yes1> |
| <yes2> |
And Result should not contain fields:
| <row> |
| <no1> |
| <no2> |
Examples:
| db | row | yes1 | yes2 | no1 | no2 | query |
| 1 | model | 1013 | 1006 | 1012 | 1007 | "SELECT model FROM pc WHERE speed >= 3.0;" |
| 1 | maker | E | A | C | H | "SELECT maker FROM product NATURAL JOIN laptop WHERE hd >= 100;" |
Scenario Outline: Testing query with 2 attributes with these 2 record in and another 2 out of result
Given I'm connected to <db> database
When I select <query> from database
Then Result should contain fields:
| <rowA> | <rowB> |
| <yes1A> | <yes1B> |
| <yes2A> | <yes2B> |
And Result should not contain fields:
| <rowA> | <rowB> |
| <no1A> | <no1B> |
| <no2A> | <no2B> |
Examples:
| db | rowA | rowB | yes1A | yes1B | yes2A | yes2B | no1A | no1B | no2A | no2B | query |
| 1 | model | price | 1004 | 649 | 2007 | 1429 | 2004 | 1150 | 3007 | 200 | "SELECT model,price FROM product" |
| 2 | name | country | Yamato | Japan | North | USA | Repulse | Brit | Cal | USA | "SELECT name, country FROM clases" |
我希望能够编写一个具有一般属性数量的场景。如果测试行数不也确定就好了。
我的梦想是写只有一个一般场景:
Testing query with N attribute with these M record in and another L out of result
如何在 Gherkin 中执行此操作?有可能有任何黑客吗?
简短的回答是,不。Gherkin 与灵活性无关,Gherkin 与具体示例有关。具体的例子就是不灵活。
长答案是:
您正在描述 Gherkin 作为测试工具的用法。然而,Gherkin 的目的不是为了测试。 Gherkin 的目的是促进开发人员与需要特定行为的利益相关者之间的沟通。
如果您想测试某些东西,还有其他工具可以完全支持您想要的东西。任何测试框架都可以使用。我个人的选择是 JUnit,因为我主要使用 Java.
决定工具的试金石是,谁必须能够理解这一点?
如果答案不是技术人员,我可能会使用 Gherkin 和非常具体的例子。具体示例很可能不会比较数据库中的内容。具体示例倾向于描述系统的外部可观察行为。
如果答案是开发人员,那么我可能会使用可以访问编程语言的测试框架。这将允许您要求的灵活性。
在您的情况下,您要求的是一种编程语言。 Gherkin 和 Cucumber 不是适合您的工具。
你可以不加任何技巧就完成,但我认为你不想,至少不是一行中的整个场景。
你会想要遵循 BDD 结构,否则为什么要使用 BDD?
您应该拥有并遵循如下结构:
Given
When
Then
您需要在初始上下文、操作和结果之间进行拆分和界定。在这些之间没有限制将是一种不好的做法。
另请注意,明确的界定将提高可重用性、可读性,并且对您的调试也有很大帮助。
Please do a research of what BDD means and how it helps, it may help if you have a checklist with best practices of BDD that could also help in code review of the automated scenarios.
我正在寻找可以构建更灵活场景的机制。
例如,对于测试数据库中记录是否存在的这两个非常相似的场景:
Scenario Outline: Testing query with 1 attribute with these 2 record in and another 2 out of result
Given I'm connected to <db> database
When I select <query> from database
Then Result should contain fields:
| <row> |
| <yes1> |
| <yes2> |
And Result should not contain fields:
| <row> |
| <no1> |
| <no2> |
Examples:
| db | row | yes1 | yes2 | no1 | no2 | query |
| 1 | model | 1013 | 1006 | 1012 | 1007 | "SELECT model FROM pc WHERE speed >= 3.0;" |
| 1 | maker | E | A | C | H | "SELECT maker FROM product NATURAL JOIN laptop WHERE hd >= 100;" |
Scenario Outline: Testing query with 2 attributes with these 2 record in and another 2 out of result
Given I'm connected to <db> database
When I select <query> from database
Then Result should contain fields:
| <rowA> | <rowB> |
| <yes1A> | <yes1B> |
| <yes2A> | <yes2B> |
And Result should not contain fields:
| <rowA> | <rowB> |
| <no1A> | <no1B> |
| <no2A> | <no2B> |
Examples:
| db | rowA | rowB | yes1A | yes1B | yes2A | yes2B | no1A | no1B | no2A | no2B | query |
| 1 | model | price | 1004 | 649 | 2007 | 1429 | 2004 | 1150 | 3007 | 200 | "SELECT model,price FROM product" |
| 2 | name | country | Yamato | Japan | North | USA | Repulse | Brit | Cal | USA | "SELECT name, country FROM clases" |
我希望能够编写一个具有一般属性数量的场景。如果测试行数不也确定就好了。
我的梦想是写只有一个一般场景:
Testing query with N attribute with these M record in and another L out of result
如何在 Gherkin 中执行此操作?有可能有任何黑客吗?
简短的回答是,不。Gherkin 与灵活性无关,Gherkin 与具体示例有关。具体的例子就是不灵活。
长答案是:
您正在描述 Gherkin 作为测试工具的用法。然而,Gherkin 的目的不是为了测试。 Gherkin 的目的是促进开发人员与需要特定行为的利益相关者之间的沟通。
如果您想测试某些东西,还有其他工具可以完全支持您想要的东西。任何测试框架都可以使用。我个人的选择是 JUnit,因为我主要使用 Java.
决定工具的试金石是,谁必须能够理解这一点?
如果答案不是技术人员,我可能会使用 Gherkin 和非常具体的例子。具体示例很可能不会比较数据库中的内容。具体示例倾向于描述系统的外部可观察行为。
如果答案是开发人员,那么我可能会使用可以访问编程语言的测试框架。这将允许您要求的灵活性。
在您的情况下,您要求的是一种编程语言。 Gherkin 和 Cucumber 不是适合您的工具。
你可以不加任何技巧就完成,但我认为你不想,至少不是一行中的整个场景。
你会想要遵循 BDD 结构,否则为什么要使用 BDD?
您应该拥有并遵循如下结构:
Given
When
Then
您需要在初始上下文、操作和结果之间进行拆分和界定。在这些之间没有限制将是一种不好的做法。
另请注意,明确的界定将提高可重用性、可读性,并且对您的调试也有很大帮助。
Please do a research of what BDD means and how it helps, it may help if you have a checklist with best practices of BDD that could also help in code review of the automated scenarios.