2

I have a Gherkin test for valid passwords. I have a list of example passwords that should pass. Now, I'd also like to be able to run the test over multiple browser types just to ensure their behavior is consistent. The following is the Chrome test:

Feature: PasswordCriteria
    New, stronger, password criteria have been implemented. We want to automate testing of the critera.

@PasswordCriteria
Scenario Template: New User / Valid Password
    Given the patient is using "chrome"
    When The user registers a new user with a valid password "<password>"
    Then No Invalid Password error message should be displayed
    Examples:
    | password             |
    | Pa12!@#]             |
    | Pa12&*(?>;           |
    | PA1234=+{/" \|\\     |
    | pa1234,<.}':abcd     |
    | ` ~_ - .$%^)abCD1234 |
    | ABCD123ef            |

I would like to be able to have a second table to iterate over the browser types (Chrome, Firefox, IE, etc), but I can't seem to build it, or find any documentation on how to build it.

Sean Duggan
  • 1,105
  • 2
  • 18
  • 48
  • On a side note, it looks like I might not be the only person looking for this now that I look around a bit more... http://stackoverflow.com/questions/29398878/is-there-a-for-each-or-equivalent-syntax-for-gherkin-cucumber – Sean Duggan Oct 22 '15 at 18:28
  • You can use configuration files to control which browser is used in your cukes. Then you can run with multiple configurations through your CI. I would not do that. The cukes you run next week should be reducing your risk of regression. Is it likely that your passwords will work on all browsers today, but one of those passwords will fail on Chrome next week? If not, then you are investing to create more time before you receive satisfactory feedback. – Dave McNulla Oct 23 '15 at 11:07
  • CI, as in Control Infrastructure? And personally, I agree with you that the standards for the passwords aren't likely to accidentally get modified in the code, but policy is that every requirement gets covered with a test, and more importantly, we want to be sure that the trigger is detected in the webpage so that the user is informed of why their password was not accepted, and the behavior does sometimes vary between browsers for that. – Sean Duggan Oct 23 '15 at 12:07
  • CI is 'continuous integration' system, such as jenkins, bamboo, or cruise control. You can create a task/job for each browser using that. With a system like that, it can run for every checking, or every night. Personally, I'd fun the key fundamental set for every check-in and the 'standards test' periodically. – Dave McNulla Oct 23 '15 at 16:15
  • Ah. Yeah, this is more for the smoke tests before a release to make sure nothing has been shaken loose and to document that we've tested our steps. Well, anyhow, it sounds like nested tables aren't going to pan out. I guess I just unroll them into a larger table, probably autogenerated by script. Thank you for your help. – Sean Duggan Oct 23 '15 at 16:25
  • I would never test every acceptance criteria on every compatible browser for a smoke test. I would change the standards. – Dave McNulla Oct 23 '15 at 16:50

1 Answers1

0

Yes one can iterate over multiple set of data by using Tables in gherkin and for details of implementation refer Thomas blog

@PasswordCriteria Scenario Template: New User / Valid Password Given the patient is using "<Browser>" When The user registers a new user with a valid password | Pa12!@#] | | Pa12&*(?>; | | PA1234=+{/" \|\\ | | pa1234,<.}':abcd | | ~_ - .$%^)abCD1234 | | ABCD123ef | Then No Invalid Password error message should be displayed Examples: | Browser | | Chrome | | Safari |

SDV
  • 89
  • 1
  • 1
  • 1
    The blog you're linking to is discussing passing a list into a function so that that function tests the list. I need a separate test for each of the combinations. – Sean Duggan Feb 04 '16 at 20:53