10

I'm creating a Scenario Outline similar to the following one (it is a simplified version but gives a good indication of my problem): 

Given I have a valid operator such as 'MyOperatorName'
    When I provide a valid phone number for the operator 
    And I provide an '<amount>' that is of the following '<type>'
    And I send a request 
    Then the following validation message will be displayed: 'The Format of Amount is not valid'
    And the following Status Code will be received: 'AmountFormatIsInvalid'

Examples:
    | type      | description                     | amount |
    | Negative  | An amount that is negative      | -1.0   |
    | Zero      | An amount that is equal to zero |  0     |
    | ......... | ..........                      | ....   |

The Examples table provides the test data that I need but I would add another Examples table with just the names of the operators (instead of MyOperatorName) in order to replicate the tests for different operators

Examples: 
   | operator  |
   | op_numb_1 |
   | op_numb_2 |
   | op_numb_3 |

in order to avoid repeating the same scenario outline three times; I know that this is not possible but I'm wondering what is the best approach to avoid using three different scenario outlines inside the feature that are pretty the same apart from the operator name. I know that I can reuse the same step definitions but I'm trying to understand if there is a best practice to prevent cluttering the feature with scenarios that are too much similar.

g.cacciapaglia
  • 259
  • 3
  • 9

1 Answers1

11

Glad you know this isn't possible... So what options are there? Seems like there are 5:

a: Make a table with every option (the cross product)

Examples:

 | type      | description                     | amount | operator  |
 | Negative  | An amount that is negative      | -1.0   | op_numb_1 |
 | Zero      | An amount that is equal to zero |  0     | op_numb_1 |
 | Negative  | An amount that is negative      | -1.0   | op_numb_2 |
 | Zero      | An amount that is equal to zero |  0     | op_numb_2 |
 | ......... | ..........                      | ....   | ...       |

b. Repeat the scenario for each operator, with a table of input rows - but you said you didn't want to do this.

c. Repeat the scenario for each input row, with a table of operators - I like this option, because each rule is a separate test. If you really, really want to ensure that every different implementation of your "operator" strategy passes and fails in the same validation scenarios, then why not write each validation scenario as a single Scenario Outline: e.g.

Scenario Outline: Operators should fail on Negative inputs
Given I have a valid operator such as 'MyOperatorName'
When I provide a valid phone number for the operator 
And I send a request with the amount "-1.0"
Then the following validation message will be displayed: 'The Format of Amount is not valid'
And the following Status Code will be received: 'AmountFormatIsInvalid'

Scenario Outline: Operators should fail on Zero inputs
...etc...

d. Rethink how you are using Specflow - if you only need KEY examples to illustrate your features (as described by Specification by Example by Gojko Adzic), then you are overdoing it by checking every combination. If however you are using specflow to automate your full suite of integration tests then your scenarios could be appropriate... but you might want to think about e.

e. Write integration / unit tests based on the idea that your "operator" validation logic is applied only in one place. If the validation is the same on each operator, why not test it once, and then have all the operators inherit from or include in their composition the same validator class?

perfectionist
  • 4,256
  • 1
  • 23
  • 34
  • 1
    To be fair, the `When I provide a valid phone number for the operator` is kind of superfluous in option c. - you could write `When I send a request with a valid phone number and the amount "-1.0"`. – perfectionist Oct 31 '13 at 17:30
  • 2
    Nice answer, I'd definitely second @perfectionist and push you down option d. Just choice example to flesh out your testing, not exhaustively testing every possible combination. If you need exhaustive testing then wire up something that can generate combinatorial tests (see mbUnit) or maybe just a console app that re-uses your Specflow bindings... – AlSki Oct 31 '13 at 17:39
  • Thanks @perfectionist, I really appreciate your answer; it is definitely complete and exhaustive. – g.cacciapaglia Oct 31 '13 at 17:43