Skip to content

Sprimber Tags

vvolverine edited this page Mar 10, 2020 · 1 revision

This page will help to understand how Sprimber manage the tags, depends on the adapter and how hook filtering actually works.

Main info

Sprimber uses tags for multiple purposes:

  1. Meta. Additional "meta" information that can be passed with scenario definition, like @story:positive or @executor:single. This information will be stored as part of tree node internally and uses for different purposes from core-related execution changes till adapter-related report perks. More information can be found below.
  2. Filtering. The tags will be processed from the source files(*.feature), matched with tag expression and based on the result corresponding node will be created and added to the execution tree or will be ignored. NOTE: the same tag can be used for both purposes at the same time.

Filtering Definitions

  • Tag - one word expression followed after sign @. Example: @smoke
  • Tag Expression - expression on specific language that allow to set the rules how to include or exclude particular nodes combining tags and operators. Example: @regression and @stable
  • Default Tag Expression - expression that set by property during the test automation start-up. The property namesprimber.configuration.tagFilters
  • Custom Tag Expression - expression that was evaluated during runtime

Cucumber Adapter

Cucumber Adapter tag filtering based on Cucumber Tag Expressions library. The official page offer nice examples and detail description for this language. There are difference between how tag filtering happens between scenarios and hooks.

Example:

@echo
Feature: This is a test feature for echo application
  @stable
  Scenario: Simple scenario to check multiple steps arguments
    Given the next author long consumed '123' and '321'

  @non_stable
  Scenario: Scenario to check failed steps
    When some when action with param 'hi'
    Then every time failed action
    And test then action

Scenarios

After parsing source files each scenario has set of joined tags from feature and scenario level. So, from example above first scenario will have @echo @stable and the second one - @echo @non_stable. For each scenario this set will be matched with default tag expression and by result ignored or included into execution. The same happens for Scenario Outline

Hooks

Depends on hook level different rules applies

Suite

All hooks that annotated with @BeforeSuite or @AfterSuite will be executed once before or after execution

Feature

The tag attribute value from annotations @BeforeFeature or @AfterFeature will be used as custom tag expression. First, scenario will be filtered by default tag expression by regular rules above, then tags from feature will be used to match with custom tag expression from annotation. If matched then hook will be added

Scenario

The tag attribute value from annotations @Before or @After will be used as custom tag expression. First, scenario will be filtered by default tag expression by regular rules above, then accumulated tags from scenario will be used to match with custom tag expression from annotation. If matched then hook will be added

Step

The tag attribute value from annotations @BeforeStep or @AfterStep will be used as custom tag expression. First, scenario will be filtered by default tag expression by regular rules above, then accumulated tags from scenario will be used to match with custom tag expression from annotation. If matched then hook will be added

Clone this wiki locally