Skip to content
Allure report logoAllure Report
Main Navigation ModulesDocumentationStart

English

Español

English

Español

Appearance

Sidebar Navigation

Introduction

Install & Upgrade

Install for Windows

Install for macOS

Install for Linux

Install for Node.js

Upgrade Allure

Getting started

How to view a report

Improving readability of your test reports

Improving navigation in your test report

Features

Test steps

Attachments

Test statuses

Sorting and filtering

Defect categories

Visual analytics

Test stability analysis

History and retries

Timeline

Export to CSV

Export metrics

Guides

JUnit 5 parametrization

JUnit 5 & Selenide: screenshots and attachments

JUnit 5 & Selenium: screenshots and attachments

Setting up JUnit 5 with GitHub Actions

Pytest parameterization

Pytest & Selenium: screenshots and attachments

Pytest & Playwright: screenshots and attachments

Pytest & Playwright: videos

Playwright parameterization

How it works

Overview

Test result file

Container file

Categories file

Environment file

Executor file

History files

Integrations

Azure DevOps

Bamboo

GitHub Actions

Jenkins

JetBrains IDEs

TeamCity

Visual Studio Code

Frameworks

Behat

Getting started

Configuration

Reference

Behave

Getting started

Configuration

Reference

Codeception

Getting started

Configuration

Reference

CodeceptJS

Getting started

Configuration

Reference

Cucumber.js

Getting started

Configuration

Reference

Cucumber-JVM

Getting started

Configuration

Reference

Cucumber.rb

Getting started

Configuration

Reference

Cypress

Getting started

Configuration

Reference

Jasmine

Getting started

Configuration

Reference

JBehave

Getting started

Configuration

Reference

Jest

Getting started

Configuration

Reference

JUnit 4

Getting started

Configuration

Reference

JUnit 5

Getting started

Configuration

Reference

Mocha

Getting started

Configuration

Reference

Newman

Getting started

Configuration

Reference

NUnit

Getting started

Configuration

Reference

PHPUnit

Getting started

Configuration

Reference

Playwright

Getting started

Configuration

Reference

pytest

Getting started

Configuration

Reference

Pytest-BDD

Getting started

Configuration

Reference

Reqnroll

Getting started

Configuration

Reference

REST Assured

Getting started

Configuration

Robot Framework

Getting started

Configuration

Reference

RSpec

Getting started

Configuration

Reference

SpecFlow

Getting started

Configuration

Reference

Spock

Getting started

Configuration

Reference

TestNG

Getting started

Configuration

Reference

Vitest

Getting started

Configuration

Reference

WebdriverIO

Getting started

Configuration

Reference

xUnit.net

Getting started

Configuration

Reference

On this page

Allure RSpec reference ​

These are the functions that you can use to integrate your RSpec tests with Allure.

Note that all the functions from the Allure module are also available via the object that RSpec passes to each test, like the t argument in the example below.

ruby
describe 'Test my website' do
  it 'test authentication' do |t|
    t.description_html 'This test attempts to log into the website using a login and a password.'
    # ...
  end
end

Metadata ​

Assign a test's description, links and other metadata.

Description ​

  • Allure::description_html: (String html)

Set the test's description.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.description_html 'This test attempts to log into the website using a login and a password.'
    # ...
  end
end

Owner ​

Set the test's owner.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.label "owner", 'John Doe'
    # ...
  end
end

Tag ​

  • Allure::tag: (String tag)

Set the test's tags.

There are three ways to add a tag to your test.

  • From within the test body, call the Allure.tag() function.

  • Add a symbol to the RSpec metadata. Allure RSpec will add a tag using the symbol's name, unless it is one of the ignored tags.

  • Add a key-value pair to the RSpec metadata. Allure RSpec will add a tag using the value, unless the key is one of the ignored tags or the value is false. The latter is convenient when you declare multiple tests in a loop and want to add or not add a tag based on a condition, as in the example below.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.tag 'Web interface'
    Allure.tag 'Authentication'
    # ...
  end
end
ruby
describe 'Test my website' do
  it 'test authentication', :'Web interface', :Authentication do
    # ...
  end
end
ruby
describe 'Test my website' do
  auth_data = [
    ['johndoe', false],
    ['[email protected]', true],
  ]
  auth_data.each do |login, using_email|
    it "test authentication as #{login}", 'Using email': using_email do
      # ...
    end
  end
end

Severity ​

  • severity: String

Set the test's severity.

By default, Allure RSpec will use the value under the severity key in the RSpec metadata. The key can be changed in the configuration.

Allowed values are: “trivial”, “minor”, “normal”, “critical”, and “blocker”.

ruby
describe 'Test my website' do
  it 'test authentication', severity: 'critical' do
    # ...
  end
end

Label ​

  • Allure::label: (String name, String value)

Set an arbitrary label for the test. This is the underlying implementation for a lot of Allure's other functions.

The first argument of the function is the label name. It can be any string.

You can call Allure.label() multiple times to create an array of values under the given name.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.label 'my custom label', 'value'
    # ...
  end
end

Allure ID (Allure TestOps) ​

  • allure_id: String

Set the test's ID.

This ID is used by the “test plan” feature in Allure TestOps to select which tests to run. Allure RSpec does not export the ID to the test results.

ruby
describe 'Test my website' do
  it 'test authentication', allure_id: '123' do
    # ...
  end
end

Link ​

  • issue: String
  • tms: String
  • Allure::add_link: (url: String, name: String?, type: String?)
  • Allure::issue: (String name, String url)
  • Allure::tms: (String name, String url)

Add a link related to the test.

In Runtime API, you can do it by calling the Allure.add_link() function. The type affects the icon that is displayed next to the link in the test report. For convenience, Allure provides two shorthand functions with pre-selected link types: Allure.issue() and Allure.tms().

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.add_link url: 'https://dev.example.com/', name: 'Website'
    Allure.issue 'AUTH-123', 'https://issues.example.com/AUTH-123'
    Allure.tms 'TMS-456', 'https://tms.example.com/TMS-456'
    # ...
  end
end

Alternatively, you can add issue links and TMS links via short identifiers in the RSpec metadata. To enable this, you need to specify link patterns in the configuration. Allure RSpec will use the patterns to process values under specific keys (defaults to issue and tms respectively, but can be changed in the configuration).

Assuming the link patterns https://issues.example.org/{} and https://tms.example.org/{}, the test in the example below will have an issue link to https://issues.example.org/AUTH-123 and a TMS link to https://tms.example.org/TMS-456.

ruby
describe 'Test my website' do
  it 'test authentication', issue: 'AUTH-123', tms: 'TMS-456' do
    # ...
  end
end

If you need to specify more than one issue link or more than one TMS link to the same test, use keys with numeric postfixes after an underscore, e.g.: issue_1, issue_2, tms_1, tms_2, etc. Allure RSpec will process each of the values as usual, ignoring the keys' postfixes.

ruby
describe 'Test my website' do
  it 'test authentication', issue_1: 'AUTH-123', issue_2: 'AUTH-124' do
    # ...
  end
end

Behavior-based hierarchy ​

  • epic: String
  • feature: String
  • story: String
  • Allure::epic: (String epic)
  • Allure::feature: (String feature)
  • Allure::story: (String story)

Assign names of epics, features or user stories for a test, as part of Allure's behavior-based hierarchy.

You can do it via the functions in Runtime API or by specifying RSpec metadata under certain keys. The keys by default are epic, feature and story, but they can be changed in the configuration.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.epic 'Web interface'
    Allure.feature 'Essential features'
    Allure.story 'Authentication'
    # ...
  end
end
ruby
describe 'Test my website' do
  it 'test authentication',
     epic: 'Web interface',
     feature: 'Essential features',
     story: 'Authentication' do
    # ...
  end
end

Suite-based hierarchy ​

  • Allure::suite: (String name)

Assign the names of parent suite, suite or sub-suite for a test, as part of Allure's suite-based hierarchy.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.label 'parentSuite' 'Web interface'
    Allure.suite 'Essential features'
    Allure.label 'subSuite', 'Authentication'
    # ...
  end
end

Test steps ​

  • AllureStepAnnotation::step: (name: String, status: Status?)
  • Allure::run_step: (String name) { (*any) -> untyped }
  • Allure::step: (name: String, status: Status) { (*any) -> untyped }

Define test steps.

There are three ways of defining a step.

  • Annotated steps

    In a class that extends AllureStepAnnotation, define a method containing a test step and add the step annotation to it, with an optional name argument (defaults to the method's name). Each time the method is called during the test execution, a new step will be created for the test report. If the method calls another function that also has the step attribute, Allure Report will create a sub-step inside the current step.

  • Block-based steps

    Write a test step inside a block for the Allure.run_step() function. If the block returns a value, Allure.run_step() will return it without modification, and it will not affect the report.

  • No-op steps

    If you call the Allure.step() function, Allure will add to the report a no-op step. This allows for a log-style reporting within a test or within a larger step. A no-op step finishes immediately after it started and cannot have any sub-steps.

    The optional second argument indicates the status that will be shown for the step in the report. Allowed values are: :passed (the default), :failed, :broken, :skipped, and :unknown.

ruby
describe 'Test my website' do
  it 'test authentication' do
    Steps.step_1
    Steps.step_2
  end
end

class Steps
  extend AllureStepAnnotation

  step 'Step 1'
  def self.step_1
    step_1_1
    step_1_2
  end

  step 'Step 1.1'
  def self.step_1_1
    # ...
  end

  step 'Step 1.2'
  def self.step_1_2
    # ...
  end

  step 'Step 2'
  def self.step_2
    step_2_1
    step_2_2
  end

  step 'Step 2.1'
  def self.step_2_1
    # ...
  end

  step 'Step 2.2'
  def self.step_2_2
    # ...
  end
end
ruby
describe 'Test my website' do
  it 'test authentication' do
    Allure.run_step 'Step 1' do

      # ...
      Allure.step name: 'Step 1.1', status: :passed

      # ...
      Allure.step name: 'Step 1.2', status: :passed
    end

    Allure.run_step 'Step 2' do

      # ...
      Allure.step name: 'Step 2.1', status: :passed

      # ...
      Allure.step name: 'Step 2.2', status: :passed
    end
  end
end

Parametrized tests ​

  • Allure::parameter: (String name, String value)

With Allure RSpec, it is very easy to implement the parametrized tests pattern, i.e. to run the same test logic with different test data. To do so, just write the test inside a loop and use the variable parameters in both its title and its body.

To display a parameter value in the test report, pass it to the Allure.parameter() function.

ruby
describe 'Test my website' do
  auth_data = [
    ['johndoe', 'qwerty'],
    ['[email protected]', 'qwerty'],
  ]
  auth_data.each do |login, password|
    it "Test authentication as '#{login}'" do
      Allure.parameter 'Login', login
      Allure.parameter 'Password', password
      # ...
    end
  end
end

Attachments ​

  • Allure::add_attachment: (name: String, source: File | String, type: String, test_case: bool?)

Add an attachment with a given name.

The content is passed in the source argument and can be a text string or a File.

To ensure that the reader's web browser will display attachments correctly, pass the appropriate media type of the content as type. The Allure::ContentType class contains some popular media types, or you can use a custom string, as long as it will be understood by the web browser when viewing the test report.

When inside a test step, the function adds the attachment to the current step by default. To add it to the whole test result instead, pass true to the optional test_case argument.

ruby
describe 'Test my website' do
  it 'test authentication' do
    # ...
    Allure.add_attachment name: 'Screenshot',
                          source: File.new('/path/to/image.png'),
                          type: Allure::ContentType::PNG
    Allure.add_attachment name: 'Data',
                          source: 'This is the file content.',
                          type: Allure::ContentType::TXT
  end
end
Pager
Previous pageConfiguration
Next pageGetting started
Powered by

Join our newsletter

Allure TestOps
  • Overview
  • Why choose us
  • Cloud
  • Self-hosted
  • Success Stories
Company
  • Documentation
  • Blog
  • About us
  • Contact
  • Events
© 2025 Qameta Software Inc. All rights reserved.