黄瓜-数据驱动的测试-同一场景中的多个相似步骤 [英] Cucumber - Data driven testing - multiple similar steps in same scenario
问题描述
我正在编写一项功能，该功能涉及像典型的电子商务应用程序一样向购物车中添加多个项目。
是这样的-
场景：应用促销
鉴于我选择了培根价值 $ 1
鉴于我选择了莴苣价值 $ 2
鉴于我选择了 Diet Coke价值 $ 5
鉴于我选择了面包值得 $ 2
然后 $ 0.5促销应申请培根
然后应将 $ 0.0促销活动应用于莴苣
然后应将 $ 0.5促销活动应用于饮食可乐
然后将 $ 1.0促销活动应用于面包
然后总支付应该是 $ 8
不用说，stepdefs.js看起来像这样：
Given（/ ^我选择值（[^^] *）的（[^^] *） $ /，function（item，price）{
// addToCart
}）;
等。
还有另一种情况相似，只是增加衣服而不是食物。
如果我使用的是方案大纲和示例，它将变为：
方案概述：应用促销
鉴于我选择了< item>价值<价格>
鉴于我选择了< item>价值<价格>
鉴于我选择了< item>价值<价格>
鉴于我选择了< item>价值<价格>
然后是<折扣>促销应适用于< item>
，然后<折扣>促销应适用于< item>
然后是<折扣>促销应适用于< item>
，然后<折扣>促销应适用于< item>
然后总支付应为 $ 8
示例：
|项目|价格|折扣|
| 培根 | $ 1 | 0.5
| 莴苣 | $ 2 | 0.0
| 饮食可乐 | $ 5 | 1.0
| 面包 | $ 2 | 0.5
但是它每行运行一次测试（所以要运行四个测试），我本质上想要正在对所有这些进行一次测试。
事实上，我想将它们作为食品添加的4个项目和衣服添加的2个项目进行运行。因此，
方案大纲：应用促销< type>
鉴于我选择了< item>价值<价格>
然后是<折扣>促销应应用于< item>
然后总付款应为< total>
示例：
类型|项目和价格和推广（可能是这样的对象？）|总
食物| [{培根-$ 1-0.5}，{生菜-$ 2-0.0}，{饮食可乐-$ 5-1.0}，{面包-$ 2-0.5}] / *接受数组* / | $ 8
的衣服| [{裤子-$ 50-10}，{衬衫-$ 25-5}] | $ 60
有可能吗？
谢谢
：这只是一个示例问题，我去除了所有并发症，这只是钉牢的版本。我的想法是找到一种在场景中使用对象数组的方法。请不要使用问题中提到的名称和数字。
在场景中放置数字是一种显着增加变更成本，同时创建脆弱测试的好方法。维护成本高。因此，请不要这样做。
此外，您并没有明确说明正在测试的内容，而是在重复自己。
从您写的内容中，我可以看到您可能在此处指定了许多不同的行为。
您应该为这些内容编写单独的方案。因此，您可能会遇到以下类似情况：
方案：促销会影响购物篮中的所有产品
假设一个购物篮有多个产品
而且我已经申请了促销
结帐时
然后我应该看到对每种产品都有折扣
方案：某些产品不可打折
处理折扣的实际值
方案：促销使用正确的折扣率
给予20％折扣的促销
和一篮子产品
到结帐处
然后我应该看到20％的折扣
等。
注意：像示例中那样进行计算是一种特别有效的方法，它使方案的维护成本很高，并增加了更改应用程序的成本。 / p>
请考虑您的示例。它有一些隐藏在图中的业务规则。其中一些可能是：
- 生菜不被促销打折
- 培根是半价（还是是否有任何数量的培根能减50c？）
...
请注意，这些规则都不是很清楚的在示例方案中指定的规则时，您必须从示例中推断（猜测）规则。
现在，所有这些规则都必须以某种方式在您的应用程序中进行编码（希望在促销和产品中）。当
- 生菜变得可打折
- 培根供应紧缺，因此您无法打折时会发生什么
使用当前的方法，结果是测试失败，您必须重新编写方案以反映您的新业务条件-这样您就大大增加了更改成本。
此内容的简单规则是不要将计算出的数字放在方案中。更完整，更复杂的规则是，场景中的所有示例都应成熟为业务规则的简洁语言表达。他们应该了解到什么，即某些产品可以有一定的折扣，而不是如何，即培根目前每磅便宜50c。然后，如果有人进行了简单的配置更改，那么培根就不再便宜了，因此您的测试就不会中断。
I am writing a feature which deals with adding multiple items to shopping cart like a typical e-commerce application.
It is something like this -
Scenario: Promotion is applied
Given I select "Bacon" worth "$1"
Given I select "Lettuce" worth "$2"
Given I select "Diet Coke" worth "$5"
Given I select "Bread" worth "$2"
Then "$0.5" promotion should be applied for "Bacon"
Then "$0.0" promotion should be applied for "Lettuce"
Then "$0.5" promotion should be applied for "Diet Coke"
Then "$1.0" promotion should be applied for "Bread"
Then total paid should be "$8"
Needless to say, the stepdefs.js look something like this:
Given(/^I select "([^"]*)" worth "([^"]*)"$/, function (item, price) {
//addToCart
});
etc.
There is another scenario which is similar and adds clothes instead of food items.
If I am using Scenario outline and Examples it turns to this:
Scenario Outline: Promotion is applied
Given I select "<item>" worth "<price>"
Given I select "<item>" worth "<price>"
Given I select "<item>" worth "<price>"
Given I select "<item>" worth "<price>"
Then "<discount>" promotion should be applied for "<item>
Then "<discount>" promotion should be applied for "<item>
Then "<discount>" promotion should be applied for "<item>
Then "<discount>" promotion should be applied for "<item>
Then total paid should be "$8"
Examples:
| item | price | discount |
| "Bacon" | "$1" | 0.5
| "Lettuce" | "$2" | 0.0
| "Diet Coke" | "$5" | 1.0
| "Bread" | "$2" | 0.5
But it runs the test once per row (so four tests are run), what I essentially want is running all of them for one test.
In fact I want to run them as 4 items added for food vs 2 items added for clothes. So,
Scenario Outline: Promotion is applied <type>
Given I select "<item>" worth "<price>"
Then "<discount>" promotion should be applied for "<item>"
Then total paid should be "<total>"
Examples:
type | items & prices & promotion (may be some object like that?) | total
food | [ {"Bacon - $1 - 0.5"}, {"Lettuce - $2 - 0.0"}, {"Diet Coke - $5 - 1.0"}, {"Bread - $2 - 0.5"} ] /*takes an array*/ | $8
clothes | [{"pant - $50 - 10"}, {"shirt - $25 - 5"}] | $60
Is it even possible? How do one achieve that?
Thanks
[EDIT]: This is just an example question, I've removed all complications and this is just a nailed down version. My idea is to get a way to use array of objects in scenarios. Please do not go by the name and numbers mentioned in the question.
Putting figures in scenarios is a really good way to dramatically increase the cost of change, whilst at the same time creating fragile tests with high maintenance costs. So don't do it.
In addition you are not clearly stating what you are testing and you are repeating yourself.
From what you have written I can see lots of different behaviour you might be specifying here.
You should write separate scenarios for these things. So you could have scenarios like
Scenario: Promotion affects all products in the basket
Given a have a basket with several products
And I have applied a promotion
When I go to the checkout
Then I should see a discount applied to each product
Scenario: Some products are not discountable
to deal with the actual value of the discount
Scenario: Correct discount rate is applied for a promotion
Given a promotion with a 20% discount
And a basket of products
When I go to the checkout
Then I should see a 20% discount
etc. etc.
Note: Doing calculations like in your examples is a particularly effective way of making your scenarios expensive to maintain, and to increase the cost of change of your application.
Consider your example. It has several business rules hidden in the figures. Some of these probably are:
- lettuce is not discounted by promotions
- bacon is half price (or is that any quantity of bacon gets 50c off?) ...
Note how none of these rules a clearly specified in you example scenarios, you have to infer (guess) the rule from the example.
Now all of these are rules that must somehow be encoded in your application (hopefully in the promotion and products). What happens when
- lettuce becomes discountable
- bacon supplies are tight so you can't discount it any more
With your current approach what happens is that you tests fail and you have to re-write the scenarios to reflect your new business conditions - so you have dramatically increased the cost of change.
The simple rule for this stuff is don't put calculated numbers in scenarios. The fuller more complex rule is that all examples in scenarios should mature into concise verbal expressions of business rules. They should capture the WHAT i.e. that some products can have a percentage discount, rather than HOW i.e. bacon is currently 50c per pound cheaper. Then if someone makes the simple config change that bacon is no longer discountable you don't have your tests breaking because of this.
这篇关于黄瓜-数据驱动的测试-同一场景中的多个相似步骤的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
