{"id":154,"date":"2020-12-09T16:25:51","date_gmt":"2020-12-09T16:25:51","guid":{"rendered":"https:\/\/kenpugh.com\/blog\/?p=154"},"modified":"2021-04-26T18:46:11","modified_gmt":"2021-04-26T18:46:11","slug":"decompose-scenarios-for-simpler-scenarios","status":"publish","type":"post","link":"https:\/\/kenpugh.com\/blog\/decompose-scenarios-for-simpler-scenarios\/","title":{"rendered":"Decompose Scenarios for Simpler Scenarios"},"content":{"rendered":"\n

A blog question on relative dates by Gojko Adzic<\/a> triggered a blog post by Seb Rose<\/a>.   The two blog posts showed there are many shades of gherkin<\/a><\/font><\/u>.  I\u2019d like to use the example in those two posts to demonstrate a couple of facets of scenario decomposition. This uses a slightly different shade than Seb’s. <\/p>\n\n\n\n\n\n\n\n

Discovery<\/strong><\/p>\n\n\n\n

Let\u2019s start with a scenario that might have been created during the discovery phase for this story. The example revolves around credit card transactions that reserve an amount of money.   If those transactions are not finalized by an actual charge within a certain amount of time, they are cancelled.   The scenarios might look like:<\/p>\n\n\n\n

Scenario: Transaction aged by one month or less remains pending\nGiven a transaction received one month ago\nWhen batch is processed\nThen transaction remains pending\nScenario: Transaction aged over one month is cancelled\nGiven a transaction received over one month ago\nWhen batch is processed\nThen transaction is cancelled<\/pre>\n\n\n\n
These scenarios assume that the customer knows about the daily batch job or else the When might be reworded to a more customer-understood term.     <\/p>\n\n\n\n
Formulation:<\/strong><\/p>\n\n\n\n
When the scenario from discovery is explored in the formulation phase, then additional scenarios may be created that capture more detail of behavior.  I differentiate between flow scenarios (like the one above) that have state (e.g. a transaction that must be created) and calculation scenarios where an algorithm or business rule yields a result.   Calculation scenarios tend to have more (or much more) detail.  <\/p>\n\n\n\n
There could be some separation of behavior in the cancellation rule.  It could be split into a calculation of the differences in two dates and a determination of the actions based on the differences.   This separation allows for more re-use in different scenarios, just like separation in code.   If the date difference calculation was previously used in an application, then there should already have been a scenario\/test for it.   If not, you collaborate on creating a scenario for it: <\/p>\n\n\n\n
Scenario:  Calculation - Difference in Two Dates\n* Difference in Months and Days between Date and Another Date\n| Date        | Another Date | Difference    | Notes       |\n| 20-Feb-2020 | 20-Mar-2020  | 1 month 0 day |  common     |\n| 19-Feb-2020 | 20-Mar-2020  | 1 month 1 day |  \u201c          |\n| 29-Feb-2020 | 31-Mar-2020  | 1 month 0 day | previous month does not have the day|\n| 29-Feb-2020 | 30-Mar-2020  | 1 month 0 day |  \"          |\n| 29-Feb-2020 | 29-Mar-2020  | 1 month 0 day |  \u201c          |<\/pre>\n\n\n\n
I typically have a Notes column on every table.  It can explain why a particular set of values is being used.  That\u2019s handy when you re-visit a scenario after enough time has passed that the reason has faded. <\/p>\n\n\n\n
I also suggest the description of the calculation be put in comments with the scenario.   Part of it might read:<\/p>\n\n\n\n
#If the previous month does not contain the day, then use the highest day available<\/pre>\n\n\n\n
This calculation can get rather complicated and messy. Take a look at Seb\u2019s blog <\/a>for even more examples.   Notice that the calculation is asymmetric.    One month after 29-Feb-2020 is 29-Mar-2020.   Once the triad starts creating this scenario, the customer might alter the requirement to something simpler, like cancel \u201cover 30 days\u201d, unless there was a legal requirement for the complexity.   In that case, the calculation scenario should be reviewed by the subject matter expert to ensure that it meets that requirement.     <\/p>\n\n\n\n
With the difference in dates separate, the cancellation rule can be stated as:<\/p>\n\n\n\n
Rule:  Cancel transactions aged over one month\n| Difference    | Category       | Action         |        \n| 1 month 0 day | one_month      | Remain pending |\n| 1 month 1 day | over_one_month | Cancel         |<\/pre>\n\n\n\n
Examples with data for a scenario could be:<\/p>\n\n\n\n
| Trans Date  | Batch Date  | Category       | Action         |\n| 20-Feb-2020 | 20-Mar-2020 | one_month      | Remain pending |\n| 19-Feb-2020 | 20-Mar-2020 | over_one_month | Cancel         |<\/pre>\n\n\n\n
Note that this business rule uses the result of the difference calculation.   Each rule\/calculation can be simpler, as each is deals with fewer of the details.   The examples of this rule utilize one of the examples in the difference calculation rule.   Note that the names of the categories should reflect the customer\u2019s terminology.  <\/p>\n\n\n\n
Let\u2019s incorporate the example data of  the cancellation rule into the flow scenario from discovery. <\/p>\n\n\n\n
Scenario: Transaction aged by one month or less remains pending\nGiven a transaction received 20-Feb-2020  \nWhen batch processed on 20-Mar-2020\nThen transaction remains pending\nScenario: Transaction aged over one month is cancelled\nGiven a transaction received 19-Feb-2020  \nWhen batch processed on 20-Mar-2020\nThen transaction is cancelled<\/pre>\n\n\n\n
Preprocessor<\/strong><\/p>\n\n\n\n
Note when actual data is incorporated, then the meaning behind that data selection is hidden.   To keep both the meaning and the data together,  I created a Gherkin preprocessor as an experiment.  It can be found at https:\/\/github.com\/atdd-bdd\/GherkinPreprocessor<\/a><\/p>\n\n\n\n
With the preprocessor, you create names for values.   You use these names in the scenario.   When the feature file is processed, the names are replaced by the values.   For example:<\/p>\n\n\n\n
#define BatchDate 20-Mar-2020\n#define OneMonthAgo 20-Feb-2020\n#define OverOneMonthAgo 19-Feb-2020\nScenario: Transaction aged by one month or less remains pending\nGiven a transaction received OneMonthAgo\nWhen batch processed on BatchDate\nThen transaction remains pending\nScenario: Transaction aged over one month is cancelled\nGiven a transaction received OverOneMonthAgo\nWhen batch processed on BatchDate\nThen transaction is cancelled<\/pre>\n\n\n\n
Notice how the scenarios appear close to the ones from discovery.  They are more abstract, but the test that is run contains specific data.  You could use whatever style you like for the #defines.  For example:  <\/p>\n\n\n\n
#define batch_date 20-Mar-2020<\/pre>\n\n\n\n
would make the step into:<\/p>\n\n\n\n
When batch processed on batch_date<\/pre>\n\n\n\n
The #defines might be changed if a different approach was needed for automation.  For example, if the date of the batch processing could not easily be set to a test date, then you might use:     <\/p>\n\n\n\n
#define BatchDate Today()\n#define OneMonthAgo TodayLess(1 month 0 day)\n#define OverOneMonthAgo TodayLess(1 month 1 day)<\/pre>\n\n\n\n
Now the dates used in the automated test will be relative to today\u2019s date.   But the scenario itself has not changed.   You could convert these symbols into the relevant values in the step definition, rather than use the preprocessor.  That would make the actual data used less transparent, which is a discussion for another article.  <\/p>\n\n\n\n
Summary:<\/p>\n\n\n\n
Splitting a story into flow scenarios and calculation scenarios can simplify each of the scenarios.  The calculation scenarios may be re-usable in other scenarios.  The advantages of smaller scenarios can parallel the advantages of smaller methods in coding.   We\u2019ll explore that in a subsequent post.  <\/p>\n","protected":false},"excerpt":{"rendered":"
A blog question on relative dates by Gojko Adzic triggered a blog post by Seb Rose.   The two blog posts showed there are many shades of gherkin.  I\u2019d like to use the example in those two posts to demonstrate a couple of facets of scenario decomposition. This uses a slightly different shade than Seb’s.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[6,9,8,7],"class_list":["post-154","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-bdd","tag-business-rules","tag-decomposition","tag-scenarios"],"_links":{"self":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts\/154","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/comments?post=154"}],"version-history":[{"count":7,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts\/154\/revisions"}],"predecessor-version":[{"id":190,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/posts\/154\/revisions\/190"}],"wp:attachment":[{"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/media?parent=154"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/categories?post=154"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kenpugh.com\/blog\/wp-json\/wp\/v2\/tags?post=154"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}