Added: Paden Detweiler - Date: 17.12.2021 13:02 - Views: 17443 - Clicks: 5258
I have a different take to Gojko, that is more in line with the community response. Here is a high-level summary of the acronym to help you read this article:. This has a of problems:. Using actual dates does appear to follow the real data principle, but is all that information actually relevant to the rule?
What does it mean? However, the first example is for 30 September, and 30 October is entirely valid, so why is this example present in this table? Quite apart from that, the rule itself seems inconsistent. The example for 31 March shows the authorisation being cancelled on 30 April, but it would appear more consistent to cancel the authorisation the day after the end of month i.
This is, of course, the decision of the product owner, but since the example is just one of many in this scenario outline it may well escape notice. As you will see in the scenarios below, this le to some very strange inconsistencies based upon my deduction of how the calculation is intended to take place. I would suggest writing a much simpler scenario to illustrate the cancellation rule. The month calculation could then be illustrated as shown in the scenarios below.
Since exhaustive scenarios like these are more like test cases than a business specification, I would not put these in the same feature file with higher level scenario above. I would either:. Notice that there is no mention of authorisation, processing, or cancellation in the follwing scenarios.
They simply illustrate how a month should be calculated. Such is life. Gojko is one of the most influential practitioners in the field and his book Bridging the communication gap is what got me interested in this approach in the first place. It was his encouragement at a conference workshop a few years ago that led me to create the BRIEF acronym.
Or, possibly, at a vegan restaurant. By Seb Rose. Specifying relative time periods in feature files. BDD Posted November 25, This has a of problems: B — although the scenario does use business language, my instinct is that there are very few customers or product owners that would be interested enough in the detail to actually read and review it in detail. Collaboration is the purpose of using business language and this sort of scenario can easily put people off.
These are two separate rules, but this scenario is attempting to illustrate both of them. Brief — the scenario outline when combined with the example tables is long. The second example in February non leap should read: 27 January 28 February cancelled The fourth example in February non leap should read: 28 January 28 February authorised The ninth example in February leap year should read: 29 January 29 February authorised The twelfth example in February leap year should read: 30 January 29 February cancelled Both tables for February are also missing any examples for authorisation dates of 31 January.
Dates Using actual dates does appear to follow the real data principle, but is all that information actually relevant to the rule? I — the examples are trying to illustrate the mechanics of how a month is calculated. A cursory reading of this example table might even give a false sense of comfort.
F — there is a rule about how a month should be calculated. Trying to illustrate this rule in a scenario that is supposed to illustrate authorisation cancellation is distracting. Using actual data, where relevant, helps reveal assumptions and edge cases. Describe the intended outcomes, rather than the mechanics by which they are achieved.
Remove any information that doesn't directly illustrate the rule.First date in Cucumber and second in
email: [email protected] - phone:(510) 488-6537 x 2919
BRIEF – the acronym