Tip # 1: Make use of tags
Tagging is a great way to group test cases. Here are some that I use frequently, which are all self-explanatory: @daily, @smoke, @archived, @slow, @security, @wip. You can also tag an AIO test case name.
Tip #2: Use waits rather than sleeps
Sleeps can be used when debugging or when needing to wait a specified amount of time but will slow down your execution cycle if you use them to wait for an element to become available.
Tip #3: Take an “outside-in” approach
Writing your Gherkin before a new feature is created is a great way to ensure you have covered requirements, especially when shared upfront with other team members to ensure you are all on the same page.
Tip #4: Use scoping for accuracy
Checking that a value appears on a page will return true if it appears anywhere on the page, potentially resulting in a false positive, but you can use ‘within’ for scoping to check that the content appears in a specific location.
Tip #5: Aim for abstraction
Your Gherkin shouldn’t reference UI components. Instead of writing “When I type my name into the username field And I click the submit button”, rather have something along the lines of “When I log in as a <userRole>”.
Tip #6: Customise your error messages
Cucumber reports don’t display the environment in which the tests are run, so if you customise your expectations to output the current URL when a test fails, this extra info can be useful.