Question

I am using Ruby on Rails 3.2.2 and Cucumber with the cucumber-rails gem. I would like to know what Cucumber tags are commonly used throughout an application or at least on what criteria I should think about those so to make tags “efficient”/”useful”. More, I would like to know “how”/”in which ways” I “could”/”should” use Cucumber tags.

Answer 1

Tags are most commonly used to select or exclude certain tests from running. Your particular situation will dictate what ‘groups’ of tests are useful to run or not run for a particular test run, but some common examples could be:

• @slow – indicates a test that takes a long time to run, you might want to exclude this from most test runs and only run it on an overnight build so that developers don’t have to wait for it every time.
• @wip – indicates that this test exercises unfinished functionality, so it would be expected to fail while the feature is in development (and when it’s done, the @wip tag would be removed). This has special significance in Cucumber as it will return a non-zero exit code if any @wip tests actually pass
• @release_x, @sprint_y, @version_z etc. Many teams tag each test with information about which release/sprint/version contains it, so that they can run a minimal suite of tests during development. Generally the same as the @wip tag except that they stay attached to the test so they always know when a particular feature was introduced.
• @payments, @search, @seo etc. Basically any logical grouping of tests that isn’t already expressed by the organisation of your feature files. Commonly used when a test relates to a cross-cutting concern, or when your project is divided into components along different lines to your feature files.

Tags are also used to fire hooks – bits of code which can run before, after, or ‘around’ tests with particular tags. Some examples of this are:

• @javascript – indicates that a test needs Javascript support, so the hook can switch from an HTTP-only driver to one with JS support. Capybara goes one step further by automatically switching to a driver named after the tag, if one is found (so you could use e.g. @desktop, @mobile, @tablet drivers)
• @logged_in – indicates that the test needs to run in the context of a logged-in user, this sometimes makes sense to express with a tag, although a Background section would be more commonly used

Additionally, tags can be used just for informational purposes. I’ve seen teams tag tests with the related issue number, author, developer, amongst other things, many of which can be useful (but many of which duplicate information which is easily found in source control, so I’d caution against that).