Allure Framework is a flexible lightweight multi-language test report tool that not only shows a very concise representation of what have been tested in a neat web report form, but allows everyone participating in the development process to extract maximum of useful information from everyday execution of tests. From the dev/qa perspective Allure reports shorten common defect lifecycle: test failures can be divided on bugs and broken tests, also logs, steps, fixtures, attachments, timings, history and integrations with TMS and bug-tracking systems can be configured, so the responsible developers and testers will have all information at hand. From the managers perspective Allure provides a clear 'big picture' of what features have been covered, where defects are clustered, how the timeline of execution looks like and many other convenient things. Modularity and extensibility of Allure guarantees that you will always be able to fine-tune something to make Allure suit you better.

1. Get Started

To generate your first report you will need to go through just a few simple steps:

  • Downloading and installing Allure commandline application suitable for your environment.

  • Locating test execution data that you have to build a report on.

1.1. Installing a commandline

Several options for Allure installation are currently supported:

1.1.1. Linux

For debian-based repositories a PPA is provided:

sudo apt-add-repository ppa:qametaio/allure-framework #not published yet
sudo apt-get update 
sudo apt-get install allure-commandline

1.1.2. Mac OS X

For Mas OS, automated installation is available via Homebrew

brew install allure

1.1.3. Windows

For Windows, Allure is available from the Scoop commandline-installer.

To install Allure, download and install Scoop and then execute in the Powershell:

scoop install allure

Also Scoop is capable of updating Allure distribution installations. To do so navigate to the Scoop installation directory and execute

\bin\checkver.ps1 allure -u

This will check for newer versions of Allure, and update the manifest file. Then execute

scoop update allure

to install a newer version. (documentation)

1.1.4. Manual installation

  1. Download the latest version as zip archive from bintray.

  2. Unpack the archive to allure-commandline directory.

  3. Navigate to bin directory.

  4. Use allure.bat for Windows or allure for other Unix platforms.

  5. Add allure to system PATH.

To run commandline application, Java Runtime Environment must be installed.

1.1.5. Check the installation

Execute allure --version in console to make sure that allure is now available:

$ allure --version
2.0.1

1.2. Test execution

Before building a report you need to run your tests to obtain some basic test report data. Typically it might be a junit-style xml report generated by nearly every popular test framework. For example, suppose you have test reports automatically created by surefire maven plugin stored in the target/surefire-reports:

Surefire report folder

1.3. Report generation

This is already enough to see the Allure report in one command:

allure serve /home/path/to/project/target/surefire-reports/

Which generates a report in temporary folder from the data found in the provided path and then creates a local Jetty server instance, serves generated report and opens it in the default browser. It is possible to use a --profile option to enable some pre-configured allure setting. junit profile is enabled by default, you will learn more about profiles in the following sections.

This would produce a report with a minimum of information extracted from the xml data that will lack nearly all of the advanced allure features but will allow you to get a nice visual representation of executed tests.

Report generated on xml data

1.4. Report structure

Once you’ve got the idea what the report does look like. You will probably want to get more data-rich reports. You might have to consider using one of the Allure adaptors for your testing framework, which will allow to collect much more information. Jump to the integrations section to learn more about integration with testing frameworks.

Typical report consists of 'Overview' tab, navigation bar, several tabs for different kinds of test data representation and test case pages for each individual test. Each Allure report is backed by a tree-like data structure, that represents a test execution process. Different tabs allow to switch between the views of the original data structure thus giving a different perspective. Note that all tree-like representations including Behaviors, Categories, xUnit and Packages support filtering and are sortable.

1.4.1. Overview page

Entry point for every report would be the 'Overview' page with dashboards and widgets:

Report overview

Overview page hosts several default widgets representing basic characteristics of your project and test environment.

  • Statistics - overall report statistics

  • Launches - if this report represents several test launches, statistics per launch will be shown here

  • Behaviors - information on results aggregated according to stories and features

  • Executors - information on test executors that were used to run the tests

  • History Trend - if tests accumulated some historical data, it’s trend will be calculated and shown on the graph.

Home page widgets are draggable and configurable. Also, Allure supports it’s own plugin system, so quite different widget layouts are possible.

Navigation bar is collapsible and enables you to switch into several of the basic results overview modes.

1.4.2. Categories

Categories tab gives you the way to create custom defects classification to apply for test results.

Categories tab

1.4.3. xUnit

On the xUnit tab a standard structural representation of executed tests, grouped by suites and classes can be found.

X Unit tab

1.4.4. Graph

Graphs allow you to see different statistics collected from the test data: statuses breakdown or severity and duration diagrams.

Dashboards tab overview

1.4.5. Timeline

Timeline tab visualizes retrospective of tests execution, allure adaptors collect precise timings of tests, and here on this tab they are arranged accordingly to their sequential or parallel timing structure.

Timeline tab overview

1.4.6. Behaviors

For Behavior-driven approach, this tab groups test results according to Feature and Story tags.

Behaviors tab overview

1.4.7. Packages

Packages tab represents a tree-like layout of test results, grouped by different packages.

Packages tab overview

1.4.8. Test case page

From some of the results overview pages described above you can go to the test case page after clicking on the individual tests. This page will typically contain a lot of individual data related to the test case: steps executed during the test, timings, attachments, test categorization labels, descriptions and links.

Test case result page

2. Glossary

Step

An atomic test logic execution unit. Each test case can consist of one or more steps. Steps allow to divide complex test cases into smaller pieces of logic. This can dramatically simplify analysis of test results because we can determine which part of a test case caused the overall test case failure.

Attachment

Any data (e.g. screenshot, log file, URL) that needs to be added to test results in order to clarify things.

Test

A procedure, either manually executed or automated, that can be used to verify that the system under test (SUT) is behaving as expected. Often called a test case.

Test case

Usually a synonym for “test.” In xUnit, it may also refer to a testcase class, which is actually a test suite factory as well as a place to put a set of related test methods.

Test fixture

Everything a system under test needs to have in place so that we can exercise the SUT for the purpose of verifying its behavior.

Test error

When a test is run, an error that keeps the test from running to completion. The error may be explicitly risen or thrown by the system under test (SUT) or by the test itself, or it may be thrown by the runtime system (e.g., operating system or virtual machine). In general, it is much easier to debug a test error than a test failure, because the root of the problem tends to be much more local to where the test error occurs. Compare with test failure and test success.

Test failure

When a test is run and the actual outcome does not match the expected outcome. Compare with test error and test success.

Test result

A test or test suite can be run many times, each time yielding a different test result.

Test run

A test or test suite can be run many times, each time yielding a different test result. Some commercial test automation tools record the results of each test run for prosperity.

Test success

A situation in which a test is run and all actual outcomes match the expected outcomes. Compare with test failure and test error.

Test suite

A way to name a collection of tests that we want to run together.

Parameter

Any data coming from outside allowing to clearly describe the test execution environment. For example, this can be an operating system version or JDK release, or the exact URL of the software installation being tested.

Behavior-driven development

A variation on the test-driven development process wherein the focus of the tests is to clearly describe the expected behavior of the system under test (SUT). The emphasis is on Tests as Documentation rather than merely using tests for verification.

Feature

A testable unit of functionality that can be built onto the evolving software system.

Story

The unit of incremental development in eXtreme Programming. A user story corresponds roughly to a “feature” in non-eXtreme Programming terminology and is typically decomposed into one or more tasks to be carried out by project team members.

System under test

Whatever thing we are testing defined from the perspective of the test, e.g. method, class, object or the entire application.

3. Features

This section describes the main features of Allure. For example, you can group your tests by stories or features, attach files, and distribute assertions over a set of custom steps, among other features. All features are supported by Java test frameworks, so we only provide Java examples here. For details on how a particular adapter works with the test framework of your choice, refer to the adapter guide.

3.1. Flaky tests

In a real life not all of your tests are stable and always green or always red. A test might start to "blink" i.e. it fails from time-to-time without any obvious reason. You could disable such a test, that is a trivial solution. However what if you do not want to do that? Say you would like to get more details on possible reasons or the test is so critical that even being flaky it provides helpful information? You have an option now to mark such tests in a special way, so resulting report will clearly show them as unstable:

@Flaky
public void aTestWhichFailsFromTimeToTime {
     ...
}

Here is what you get in the report in case if such test failed:

+ image::flaky_failed.png[A failed test marked as flaky]

Additional note - you could mark a whole test class as flaky as well.

4. Integration

4.1. TestNG

An Allure report can be generated for any TestNG test. In order to get test results, you need to:

  • Setup latest allure-commandline version.

  • Add allure-testng dependency.

  • Add aspectjweaver dependency and its properties.

  • Run tests.

4.1.1. Installation

Maven

You need to add the following to your pom.xml:

pom.xml
<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <compiler.plugin.version>3.6.0</compiler.plugin.version>
    <java.version>1.8</java.version>
    <surefire.plugin.version>2.19.1</surefire.plugin.version>
    <allure.version>2.0-BETA6</allure.version>
    <aspectj.version>1.8.10</aspectj.version>
    <allure.results.directory>
        ${project.build.directory}/allure-results
    </allure.results.directory>
    <tms>
        https://github.com/allure-framework/allure-docs/issues/{}
    </tms>
    <issues.tracker>
        https://github.com/allure-framework/allure-docs/issues/{}
    </issues.tracker>
</properties>

<dependencies>
    <dependency>
        <groupId>io.qameta.allure</groupId>
        <artifactId>allure-testng</artifactId>
        <version>${allure.version}</version>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>${compiler.plugin.version}</version>
            <configuration>
                <source>${java.version}</source>
                <target>${java.version}</target>
            </configuration>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>${surefire.plugin.version}</version>
            <configuration>
                <properties>
                    <property>
                        <name>usedefaultlisteners</name>
                        <value>false</value>
                    </property>
                </properties>
                <systemProperties>
                    <property>
                        <name>allure.results.directory</name>
                        <value>${allure.results.directory}</value>
                    </property>
                    <property>
                        <name>allure.link.issue.pattern</name>
                        <value>${issues.tracker}</value>
                    </property>
                    <property>
                        <name>allure.link.tms.pattern</name>
                        <value>${tms}</value>
                    </property>
                </systemProperties>
                <suiteXmlFiles>
                    <suiteXmlFile>
                        src/test/resources/testng.xml
                    </suiteXmlFile>
                </suiteXmlFiles>
                <argLine>
                    -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
                </argLine>
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>org.aspectj</groupId>
                    <artifactId>aspectjweaver</artifactId>
                    <version>${aspectj.version}</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>

Then run the build as usual:

$ mvn clean test

Allure results will appear in target/allure-results folder. To generate html report and automatically open it in a web browser, run the following command:

$ allure serve target/allure-results
Gradle

You need to add the following to build.gradle:

build.gradle
apply plugin: 'java'

sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8

configurations {
    agent
}

dependencies {
    agent "org.aspectj:aspectjweaver:1.8.10"
    compile "io.qameta.allure:allure-testng:2.0-BETA6"
}

test.doFirst {
    jvmArgs "-javaagent:${configurations.agent.singleFile}"
}

test {
    useTestNG() {
        suites 'src/test/resources/testng.xml'
    }

    systemProperty 'allure.results.directory', 'build/allure-results'
    systemProperty 'allure.link.issue.pattern', 'https://github.com/allure-framework/allure-docs/issues/{}'
    systemProperty 'allure.link.tms.pattern', 'https://github.com/allure-framework/allure-docs/issues/{}'
}

Then run the build as usual:

$ ./gradlew clean test

Allure results will appear in build/allure-results folder. To generate html report and automatically open it in a web browser, run the following command:

$ allure serve build/allure-results

4.1.2. Features

This adapter comes with a set of Java annotations and traits allowing to use main Allure features.

Steps

Steps are any actions that constitute a testing scenario. Steps can be used in different testing scenarios. They can: be parametrized, make checks, have nested steps, and create attachments. Each step has a name.

In order to define steps in Java code, you need to annotate the respective methods with @Step annotation. When not specified, the step name is equal to the annotated method name converted to human-readable format.

Note that steps' mechanics was revised and now it supports smart fields' analysis. In Allure 1 users had to specify indexes to refer which args' values they want to inject into step. Allure 2 uses reflection-based approach, which provides deep fields' extraction by their names.

Assuming that you have the following entity:

public class User {

     private String name;
     private String password;
     ...
}

You can access these fields' values directly by name:

@Step("Type {user.name} / {user.password}.")
public void loginWith(User user) {
     ...
}

Arrays and Collections are supported as well. So you don’t need to explicitly override toString() for your custom objects anymore.

Attachments

An attachment in Java code is simply an utility method addAttachment that accepts different arguments such as name, MIME type, content and file extension. Attachments could be added to either individual steps or the entire test case.

@Step
public MyPage doSomething() {
    ...
    Allure.addAttachment("Log", "text/plain", "additionalStepLog");
    return this;
}
BaseListener.java
public class BaseListener implements IInvokedMethodListener {

    @Override
    public void beforeInvocation(IInvokedMethod method, ITestResult testResult) {
    }

    @Override
    public void afterInvocation(IInvokedMethod method, ITestResult testResult) {
        if (method.isTestMethod())
            Allure.addAttachment("Screenshot", "image/png",
                new ByteArrayInputStream(getDriver().getScreenshotAs(OutputType.BYTES)), "png");
    }
}

Note that Allure 2 also supports async attachments, which are especially useful with heavy files, like videos or HARs. So you don’t need to block test execution and wait until resources are finalized.

BaseListener.java
public class BaseListener implements IInvokedMethodListener, ISuiteListener {

        private static final List<CompletableFuture<InputStream>> VIDEOS =
                new CopyOnWriteArrayList<>();

        @Override
        public void beforeInvocation(IInvokedMethod method, ITestResult testResult) {
        }

        @Override
        public void afterInvocation(IInvokedMethod method, ITestResult testResult) {
                if (method.isTestMethod()) {
                        VIDEOS.add(addStreamAttachmentAsync("Async", "video/mp4",
                                        () -> getClass().getResourceAsStream("/video.mp4")));
                }
        }

        @Override
        public void onStart(ISuite suite) {
        }

        @Override
        public void onFinish(ISuite suite) {
                CompletableFuture.allOf(VIDEOS.stream()
                        .toArray(CompletableFuture[]::new)).join();
        }
}

You can call the following methods to perform async attachments: addStreamAttachmentAsync and addByteAttachmentAsync. Both return CompletableFuture, which could be then easily managed on client side.

Issues Tracker

To link a test case or a test suite to such issues, you can use @Issue annotation. Simply specify the issue key as shown below:

@Issue("MYISSUE-1")
public void testSomething() {
     ...
}

To add multiple issues, you can use repeatable @Issue annotation:

@Issue("MYISSUE-1")
@Issue("MYISSUE-2")
public void testSomething() {
     ...
}

To specify the issue tracker URL, use the allure.link.issue.pattern property during tests execution (either as a system or your build tool property):

pom.xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>${surefire.plugin.version}</version>
            <configuration>
                ...
                <systemProperties>
                    <property>
                        <name>allure.link.issue.pattern</name>
                        <value>https://github.com/allure-framework/allure-docs/issues/{}</value>
                    </property>
                </systemProperties>
            </configuration>
        </plugin>
    </plugins>
</build>
$ mvn clean test -Dallure.link.issue.pattern=https://github.com/allure-framework/allure-docs/issues/{}

Where {} is a placeholder for keys, specified in @Issue annotations.

Test Management System

To link a test case to Test Management System, you can use @TmsLink annotation. Simply specify the test case ID as shown below:

@TmsLink("TMS-1")
public void testSomething() {
     ...
}

To specify the test management system URL, use the allure.link.tms.pattern property during tests execution (either as a system or your build tool property):

pom.xml
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>${surefire.plugin.version}</version>
            <configuration>
                ...
                <systemProperties>
                    <property>
                        <name>allure.link.tms.pattern</name>
                        <value>https://github.com/allure-framework/allure-docs/issues/{}</value>
                    </property>
                </systemProperties>
            </configuration>
        </plugin>
    </plugins>
</build>
$ mvn clean test -Dallure.link.tms.pattern=https://github.com/allure-framework/allure-docs/issues/{}

Where {} is a placeholder for keys, specified in @TmsLink annotations.

Severity

@Severity annotation is used in order to prioritize test methods by severity:

@Test
@Severity(SeverityLevel.CRITICAL)
public void testSomething() {
     ...
}
Behaviours Mapping

In some development approaches tests are classified by stories and features. If you’re using this then you can annotate your test with @Story and @Feature annotations:

@Test
@Feature("test-case-feature")
@Story("test-case-story")
public void testSomething() {
     ...
}

Note that a single test may have multiple @Story and @Feature annotations. You will then be able to filter tests by specified features and stories in generated Allure report.

Flaky tests

In order to attract developers' / QA’s attention to unstable tests, you can mark them with special @Flaky annotation. Such tests will have a bomb icon in generated html report.

@Test
@Flaky
public void testSomething() {
     ...
}

4.2. jUnit 4

4.2.1. Installation

Maven

You need to add the following to your pom.xml:

pom.xml
...
<properties>
    <aspectj.version>1.7.4</aspectj.version>
    <allure.version>{latest-allure-version}</allure.version>
</properties>

<dependencies>
    <dependency>
        <groupId>ru.yandex.qatools.allure</groupId>
        <artifactId>allure-junit-adaptor</artifactId>
        <version>${allure.version}</version>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.14</version>
            <configuration>
                <testFailureIgnore>false</testFailureIgnore>
                <argLine>
                    -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
                </argLine>
                <properties>
                    <property>
                        <name>listener</name>
                        <value>ru.yandex.qatools.allure.junit.AllureRunListener</value>
                    </property>
                </properties>
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>org.aspectj</groupId>
                    <artifactId>aspectjweaver</artifactId>
                    <version>${aspectj.version}</version>
                </dependency>
            </dependencies>
        </plugin>
    </plugins>
</build>
...

Then run the build as usual:

$ mvn clean test
Ant

Right now using Allure with Ant is not possible, because the RunListener that we provide is only supported in JUnit 4, whereas even the latest version of Ant requires the implementation of JUnit 3 specific interfaces.

4.2.2. Features

This adapter comes with a set of Java annotations and traits allowing to use main Allure features.

Title

In order to add such title to any test class or test case method you need to annotate it with @Title annotation:

package my.company.tests;

import org.junit.Test;
import ru.yandex.qatools.allure.annotations.Title;

@Title("Human-readable test suite title")
public class SearchTest {

    @Test
    @Title("Human-readable test case title")
    public void searchTest() throws Exception {
        ...
    }

}
Description

Similarly you can add detailed description for each test class and test method.

To add such description simply use @Description annotation:

package my.company.tests;

import org.junit.Test;
import ru.yandex.qatools.allure.annotations.Description;

@Test
@Description(
        value = "Detailed description for this <a href="...">test suite</a>.",
        type = DescriptionType.HTML
)
public class SearchTest {

    @Test
    @Description(
            value = "Detailed description for this *test case*.",
            type = DescriptionType.MARKDOWN
    )
    public void searchTest() throws Exception {
        ...
    }

}

Description can be added in plain text, HTML or Markdown format - simply assign different type value.

Steps

Steps are any actions that constitute a testing scenario. Steps can be used in different testing scenarios. They can: be parametrized, make checks, have nested steps, and create attachments. Each step has a name.

In order to define steps in Java code, you need to annotate the respective methods with @Step annotation. When not specified, the step name is equal to the annotated method name converted to human-readable format. To define an explicit step name:

@Step("Open {0} page.")
public void openPageByAddress(String pageAddress) {
     ...
}

Step names support the following placeholders:

  • {N} where N is a zero-based positive integer that will be replaced by the Nth method argument value (0 corresponds to the first argument, 1 to the second, etc.). See example above.

  • {method} will be replaced by the annotated method name e.g. openPageByAddress

Depending on the project layout, you can consider adding Allure dependency to the test scope only.

Attachments

An attachment in Java code is simply a method annotated with @Attachment that returns either a String or byte[], which should be added to the report:

@Attachment
public String performedActions(ActionSequence actionSequence) {
    return actionSequence.toString();
}

@Attachment(value = "Page screenshot", type = "image/png")
public byte[] saveScreenshot(byte[] screenShot) {
    return screenShot;
}

If return type in a method annotated with @Attachment differs from String or byte[] we call toString() on return value to get attachment contents.

You can specify exact MIME type for each attached file using type parameter of @Attachment annotation like shown above. However there’s no need to explicitly specify attachment type for all attached files as Allure by default analyses attachment contents and can determine attachment type automatically. You usually need to specify attachment type when working with plain text files.

Issues Tracker

To link a test case or a test suite to such issues, you can use @Issue annotation. Simply specify the issue key as shown below:

@Issue("MYISSUE-1")
public void testSomething() {
     ...
}

To add multiple issues, use @Issues annotation:

@Issues({
    @Issue("MYISSUE-1"),
    @Issue("MYISSUE-2")
})
public void testSomething() {
     ...
}

To specify the issue tracker URL, use the allure.issues.tracker.pattern property during report generation (either in the allure.properties file or as your build tool property):

allure.issues.tracker.pattern=http://github.com/allure-framework/allure-core/issues/%s
Test Management System

To link a test case to Test Management System, you can use @TestCaseId annotation. Simply specify the test case ID as shown below:

@TestCaseId("TMS-1")
public void testSomething() {
     ...
}
Parameters

In order to add information about test method parameters you should use @Parameter annotation:

package my.company.tests;

import org.junit.Test;
import ru.yandex.qatools.allure.annotations.Parameter;

public class SearchTest {

    @Parameter("Base web driver url")
    private final String baseUrl = "http://...";

    @Test
    public void searchTest() throws Exception {

    }

}
Severity

@Severity annotation is used in order to prioritize test methods by severity:

package my.company.tests;

import org.junit.Test;
import ru.yandex.qatools.allure.annotations.Severity;
import ru.yandex.qatools.allure.model.SeverityLevel;

public class SearchTest {

    @Test
    @Severity(SeverityLevel.CRITICAL)
    public void searchTest() throws Exception {

    }

}
Behaviours Mapping

In some development approaches tests are classified by stories and features. If you’re using this then you can annotate your test with @Stories and @Features annotations:

package my.company.tests;

import org.junit.Test;
import ru.yandex.qatools.allure.annotations.Features;
import ru.yandex.qatools.allure.annotations.Stories;

@Features({"nested-test-cases-feature"})
@Stories({"nested-test-cases-story"})
public class SearchTest {

    @Test
    @Features({"test-case-feature"})
    @Stories({"test-case-story"})
    public void searchTest() throws Exception {
        ...
    }

}

You will then be able to filter tests by specified features and stories in generated Allure report.

4.3. Pytest

This plugin currently supports only Allure 1.4.x series.

4.3.1. Installation and Usage

py.test --alluredir [path_to_report_dir]
# WARNING [path_to_report_dir] will be purged at first run

This plugin gets automatically connected to py.test via entry point if installed.

Connecting to IDE:

pytest_plugins = 'allure.pytest_plugin',\

4.3.2. Features

Title
Not implemented now
Description
Not implemented now
Steps

To divide a test into steps:

import pytest

def test_foo():
    with pytest.allure.step('step one'):
        # do stuff

    with pytest.allure.step('step two'):
        # do more stuff

Can also be used as decorators. By default step name is generated from method name:

import pytest

@pytest.allure.step
def make_test_data_foo():
    # do stuff

def test_foo():
    assert make_some_data_foo() is not None

@pytest.allure.step('make_some_data_foo')
def make_some_data_bar():
    # do another stuff

def test_bar():
    assert make_some_data_bar() is not None

Steps can also be used without pytest. In that case instead of pytest.allure.step simply use allure.step:

import allure

@allure.step('some operation')
def do_operation():
    # do stuff

allure.step decorator supports step name formatting with function parameters:

import allure

@allure.step('some operation for bar={0}')
def do_operation(bar):
    # do stuff

def test_foo():
    assert do_operation('abcdef')

The step in the latter case will have name some operation for bar=abcdef. Formatting is done via python’s built-in string.format and supports it’s options. Arguments are passed to format method in the same way they are passed to the decorated function.

Steps support is limited when used with fixtures.

Attachments

To attach some content to test report:

import allure

def test_foo():
    allure.attach('my attach', 'Hello, World')
Issues Tracker

Issues can be set for test.

import pytest

@pytest.allure.issue('http://jira.lan/browse/ISSUE-1')
def test_foo():
    assert False
import allure

@allure.issue('http://jira.lan/browse/ISSUE-2')
class TestBar:

    # test will have ISSUE-2, ISSUE-3 and ISSUE-4 label
    @allure.issue('http://jira.lan/browse/ISSUE-3')
    def test_bar1(self):
        # You can use this feature like a function inside the test
        allure.dynamic_issue('http://jira.lan/browse/ISSUE-4')
        pass

    # test will have only ISSUE-2 label
    def test_bar2(self):
        pass
Test Management System

Test cases links can be set for test also.

import pytest

@pytest.allure.testcase('http://my.tms.org/TESTCASE-1')
def test_foo():
    assert False
import allure

@allure.testcase('http://my.tms.org/browse/TESTCASE-2')
class TestBar:

    # test will have TESTCASE-2 and TESTCASE-3 label
    @allure.testcase('TESTCASE-3')
    def test_bar1(self):
        pass

    # test will have only TESTCASE-2 label
    def test_bar2(self):
        pass
Parameters
Not implemented now
Severity

Any test, class or module can be marked with different severity:

import pytest

@pytest.allure.severity(pytest.allure.severity_level.MINOR)
def test_minor():
    assert False


@pytest.allure.severity(pytest.allure.severity_level.CRITICAL)
class TestBar:

    # will have CRITICAL priority
    def test_bar(self):
        pass

    # will have BLOCKER priority via a short-cut decorator
    @pytest.allure.BLOCKER
    def test_bar(self):
        pass

To run tests with concrete priority:

py.test my_tests/ --allure_severities=critical,blocker
Behaviours Mapping

Feature and Story can be set for test.

import allure


@allure.feature('Feature1')
@allure.story('Story1')
def test_minor():
    assert False


@allure.feature('Feature2')
@allure.story('Story2', 'Story3')
@allure.story('Story4')
 class TestBar:

    # will have 'Feature2 and Story2 and Story3 and Story4'
    def test_bar(self):
        pass

To run tests by Feature or Story:

py.test my_tests/ --allure_features=feature1,feature2
py.test my_tests/ --allure_features=feature1,feature2 --allure_stories=story1,story2
Environment Parameters

You can provide test environment parameters such as report name, browser or test server address to allure test report.

import allure
import pytest


def pytest_configure(config):
    allure.environment(report='Allure report', browser=u'Я.Браузер')


@pytest.fixture(scope="session")
def app_host_name():
    host_name = "my.host.local"
    allure.environment(hostname=host_name)
    return host_name


@pytest.mark.parametrize('country', ('USA', 'Germany', u'Россия', u'Япония'))
def test_minor(country):
    allure.environment(country=country)
    assert country

More details about allure environment you can know from https://github.com/allure-framework/allure-core/wiki/ Environment[documentation].

4.3.3. Development

Use allure.common.AllureImpl class to bind your logic to this adapter.

4.4. PHPUnit

This an official PHPUnit adapter for Allure Framework - a flexible, lightweight and multi-language framework for writing self-documenting tests.

4.4.1. What is this for?

The main purpose of this adapter is to accumulate information about your tests and write it out to a set of XML files: one for each test class. Then you can use a standalone command line tool or a plugin for popular continuous integration systems to generate an HTML page showing your tests in a good form.

4.4.2. Example project

4.4.3. How to generate report

This adapter only generates XML files containing information about tests. See wiki section on how to generate report.

4.4.4. Installation && Usage

Note: this adapter supports Allure 1.4.x only. In order to use this adapter you need to add a new dependency to your composer.json file:

{
    "require": {
        "php": ">=5.4.0",
        "allure-framework/allure-phpunit": "~1.2.0"
    }
}

Then add Allure test listener in phpunit.xml file:

<listeners>
    <listener class="Yandex\Allure\Adapter\AllureAdapter" file="vendor/allure-framework/allure-phpunit/src/Yandex/Allure/Adapter/AllureAdapter.php">
        <arguments>
            <string>build/allure-results</string> <!-- XML files output directory -->
            <boolean>true</boolean> <!-- Whether to delete previous results on rerun -->
            <array> <!-- A list of custom annotations to ignore (optional) -->
                <element key="0">
                    <string>someCustomAnnotation</string>
                </element>
            </array>
        </arguments>
    </listener>
</listeners>

After running PHPUnit tests a new folder will be created (build/allure-results in the example above). This folder will contain generated XML files. See framework help for details about how to generate report from XML files. By default generated report will only show a limited set of information but you can use cool Allure features by adding a minimum of test code changes. Read next section for details.

4.4.5. Main features

This adapter comes with a set of PHP annotations and traits allowing to use main Allure features.

Human-readable test class or test method title

In order to add such title to any test class or test case method you need to annotate it with @Title annotation:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Annotation\Title;

/**
 * @Title("Human-readable test class title")
 */
class SomeTest extends PHPUnit_Framework_TestCase
{
    /**
     * @Title("Human-readable test method title")
     */
    public function testCase()
    {
        //Some implementation here...
    }
}
Extended test class or test method description

Similarly you can add detailed description for each test class and test method. To add such description simply use @Description annotation:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Annotation\Description;
use Yandex\Allure\Adapter\Model\DescriptionType;

/**
 * @Description("Detailed description for test class")
 */
class SomeTest extends PHPUnit_Framework_TestCase
{
    /**
     * @Description(value = "Detailed description for <b>test class</b>.", type = DescriptionType::HTML)
     */
    public function testCase()
    {
        //Some implementation here...
    }
}

Description can be added in plain text, HTML or Markdown format - simply assign different type value.

Set test severity

@Severity annotation is used in order to prioritize test methods by severity:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Annotation\Severity;
use Yandex\Allure\Adapter\Model\SeverityLevel;

class SomeTest extends PHPUnit_Framework_TestCase
{
    /**
     * @Severity(level = SeverityLevel::MINOR)
     */
    public function testCase()
    {
        //Some implementation here...
    }
}
Specify test parameters information

In order to add information about test method parameters you should use @Parameter annotation:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Annotation\Parameter;
use Yandex\Allure\Adapter\Model\ParameterKind;

class SomeTest extends PHPUnit_Framework_TestCase
{
    /**
     * @Parameter(name = "param1", value = "value1")
     * @Parameter(name = "param2", value = "value2", kind = ParameterKind::SYSTEM_PROPERTY)
     */
    public function testCase()
    {
        //Some implementation here...
    }
}
Map test classes and test methods to features and stories

In some development approaches tests are classified by stories and features. If you’re using this then you can annotate your test with @Stories and @Features annotations:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Annotation\Features;
use Yandex\Allure\Adapter\Annotation\Stories;

/**
 * @Stories({"story1", "story2"})
 * @Features({"feature1", "feature2", "feature3"})
 */
class SomeTest extends PHPUnit_Framework_TestCase
{
    /**
     * @Features({"feature2"})
     * @Stories({"story1"})
     */
    public function testCase()
    {
        //Some implementation here...
    }
}

You will then be able to filter tests by specified features and stories in generated Allure report.

Attach files to report

If you wish to attach some files generated during PHPUnit run (screenshots, log files, dumps and so on) to report - then you need to use AttachmentSupport trait in your test class:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Support\AttachmentSupport;

class SomeTest extends PHPUnit_Framework_TestCase
{

    use AttachmentSupport;

    public function testCase()
    {
        //Some implementation here...
        $filePath = $this->outputSomeContentToTemporaryFile();
        $this->addAttachment($filePath, 'Attachment human-readable name', 'text/plain');
        //Some implementation here...
    }

    private function outputSomeContentToTemporaryFile()
    {
        $tmpPath = tempnam(sys_get_temp_dir(), 'test');
        file_put_contents($tmpPath, 'Some content to be outputted to temporary file.');
        return $tmpPath;
    }

}

In order to create an attachment simply call AttachmentSupport::addAttachment() method. This method accepts attachment type, human-readable name and a string either storing full path to the file we need to attach or file contents.

Divide test methods into steps

Allure framework also supports very useful feature called steps. Consider a test method which has complex logic inside and several assertions. When an exception is thrown or one of assertions fails sometimes it’s very difficult to determine which one caused the failure. Allure steps allow to divide test method logic into several isolated pieces having independent run statuses such as passed or failed. This allows to have much more cleaner understanding of what really happens. In order to use steps simply import StepSupport trait in your test class:

namespace Example\Tests;

use PHPUnit_Framework_TestCase;
use Yandex\Allure\Adapter\Support\StepSupport;

class SomeTest extends PHPUnit_Framework_TestCase
{

    use StepSupport;

    public function testCase()
    {
        //Some implementation here...
        $this->executeStep("This is step one", function () {
            $this->stepOne();
        });

        $this->executeStep("This is step two", function () {
            $this-stepTwo();
        });

        $this->executeStep("This is step three", function () {
            $this->stepThree('someArgument');
        });
        //Some implementation here...
    }

    private function stepOne()
    {
        //Some implementation here...
    }

    private function stepTwo()
    {
        //Some implementation here...
    }

    private function stepThree($argument)
    {
        //Some implementation here...
    }

}

The entire test method execution status will depend on every step but information about steps status will be stored separately.

4.5. Jasmine

A plugin for Allure report generation from Jasmine tests.

4.5.1. Installation

From Jasmine2

Add the lib into package.json and then configure the plugin:

// conf.js
var AllureReporter = require('jasmine-allure-reporter');
jasmine.getEnv().addReporter(new AllureReporter({
  resultsDir: 'allure-results'
}));
From Protractor

Put the above code into the onPrepare inside of your conf.js:

// conf.js
exports.config = {
  framework: 'jasmine2',
  onPrepare: function() {
    var AllureReporter = require('jasmine-allure-reporter');
    jasmine.getEnv().addReporter(new AllureReporter({
      resultsDir: 'allure-results'
    }));
  }
}

4.5.2. Generate HTML report from Allure results

The Reporter will generate xml files inside of a resultsDir, then we need to generate HTML out of them. You can use Maven for that. Copy ready-to-use pom.xml from node_modules/jasmine-allure-reporter and run:

mvn site -Dallure.results_pattern=allure-results

It will put HTMLs into target/site/allure-maven-plugin folder. To serve them via localhost:1324 use:

mvn jetty:run -Djetty.port=1234

Otherwise choose one of the other ways to generate HTML.

4.5.3. Features

This adapter provides a set of methods that can be called from the global Jasmine2AllureReporter object. It wraps common allure JS adapter and provides access to basic Allure features implemented there.

Title
TBD it is not implemented currently
Description

In order to add a detailed description for a test you should call a setDescription(description) method where description is your string argument.

code snippet TBD
Severity

You can specify a severity attribute for a test via severity(severity) method where severity argument can hold one of the following pre-defined values:

  • BLOCKER

  • CRITICAL

  • NORMAL

  • MINOR

  • TRIVIAL

code snippet TBD
Behaviours

In some development approaches tests are classified by stories and features. If you’re using this, then for each test you can set story and feature attributes via story(story) and feature(feature) methods respectively, accepting story or feature as a string argument.

code snippet TBD
Steps

Steps are needed to specify actions that constitute a testing scenario. Steps are named, they can create attachments and can be used in different testing scenarios. You can add a step via createStep(name, stepFunc) method, where

  • name is a string arg bearing step name

  • stepFunc is a wrapped function whose logic this step represents in the report.

code snippet TBD
Attachments

You can add an attachment for one of the steps via createAttachment(name, content, type) method here

  • name is a string bearing attachment’s description

  • content is either a function, returning attachment object or the attachment object itself.

  • type is a string parameter to specify exact MIME type for each attached file. However there’s no need to specify attachment explicitly type for all attached files as Allure by default analyses attachment contents and can determine attachment type automatically. You usually need to specify attachment type when working with plain text files.

Example: adding a screenshot in the end of each test

  onPrepare: function () {
    var AllureReporter = require('jasmine-allure-reporter');
    jasmine.getEnv().addReporter(new AllureReporter());
    jasmine.getEnv().afterEach(function(done){
      browser.takeScreenshot().then(function (png) {
        allure.createAttachment('Screenshot', function () {
          return new Buffer(png, 'base64')
        }, 'image/png')();
        done();
      })
    });
  }

Note done callback!

Issues Tracker
Integration with bug tracker system is not currently implemented
Test Management System
Integration with test management system is not currently implemented
Parameters

In order to add information about test method parameters you should use one of the methods:

  1. addArgument(name, value) - to specify more information on one of the test arguments

  2. addEnvironment(name, value) - to specify more information on some of the environment variables

code snippet TBD

4.5.4. TBD

  • Currently attachments are added to the test case instead of the current step. This needs to be fixed in allure-js-commons.

  • Add support for Features.

  • Add support to Jasmine1. Right now only Jasmine2 is available (do we really need this?).

  • Add ability to use reflection for decoration method of page objects so that we don’t need to write Allure-related boilerplate tying ourselves to one specific reporter.

4.5.5. For Developers

See the system tests to quickly check how the reporter works in real life:

node_modules/protractor/bin/protractor ./test/system/conf.js

4.6. Cucumber

This page describes Allure adaptor usage for Cucumber framework.

4.6.1. Installation

Add this line to your application’s Gemfile:

gem 'allure-cucumber'

And then execute:

$ bundle

Or install it yourself as:

$ gem install allure-cucumber

4.6.2. Configuration

By default, Allure XML files are stored in gen/allure-results. To change this add the following in features/support/env.rb file:

AllureCucumber.configure do |c|
   c.output_dir = "/output/dir"
end

By default, the Allure XML files from earlier runs are deleted at the start of new run. This can be disabled by:

AllureCucumber.configure do |c|
  c.clean_dir  = false
end

By default, allure-cucumber will analyze your cucumber tags looking for Test Management, Issue Management, and Severity hooks. These hooks will be displayed in the generated allure report (see allure-core for further info).

    DEFAULT_TMS_PREFIX      = '@TMS:'
    DEFAULT_ISSUE_PREFIX    = '@ISSUE:'
    DEFAULT_SEVERITY_PREFIX = '@SEVERITY:'

Example:

  @SEVERITY:trivial @ISSUE:YZZ-100 @TMS:9901
  Scenario: Leave First Name Blank
    When I register an account without a first name
    Then exactly (1) [validation_error] should be visible

You can configure what allure-cucumber looks for by making the following changes

AllureCucumber.configure do |c|
  c.clean_dir  = false
  c.tms_prefix      = '@HIPTEST--'
  c.issue_prefix    = '@JIRA++'
  c.severity_prefix = '@URGENCY:'
end

Example:

  @URGENCY:critical @JIRA++YZZ-100 @HIPTEST--9901
  Scenario: Leave First Name Blank
    When I register an account without a first name
    Then exactly (1) [validation_error] should be visible

4.6.3. Usage

Put the following in your features/support/env.rb file:

require 'allure-cucumber'

Use --format AllureCucumber::Formatter --out where/you-want-results while running cucumber or add it to cucumber.yml

You can also attach screenshots, logs or test data to steps.

 #file: features/support/env.rb
 include AllureCucumber::DSL
 attach_file(title, file)

4.6.4. How to generate report

This adapter only generates XML files containing information about tests. See wiki section on how to generate report.

4.7. Cucumber JS

Allure report version supported : 1.4.15

4.7.1. Usage:

Add reporter.js file in feature packages with:

var reporter = require('cucumberjs-allure-reporter');
reporter.config(
    {...}
);
module.exports = reporter;

Supported configuration keys:

  • targetDir - directory where allure will save results xml’s

  • labels - custom label matchers, example:

labels : {
        feature: [/sprint-(\d*)/, /release-(\d)/, /area-(.*)/],
        issue: [/(bug-\d*)/]
    }

Possible labels:

  • feature

  • story

  • severity

  • language

  • framework

  • issue

  • testId

  • host

  • thread

If you want to cancel step or test, simply throw new Error with message 'Step cancelled' or 'Test cancelled'.

4.7.2. Generate HTML report from Allure results

The Reporter will generate xml files inside of a targetDir, then we need to generate HTML out of them. You can use Maven for that. Copy ready-to-use pom.xml from node_modules/cucumberjs-allure-reporter and run:

mvn site -Dallure.results_pattern=allure-results

It will put HTMLs into target/site/allure-maven-plugin folder. To serve them via localhost:1234 use:

mvn jetty:run -Djetty.port=1234

Otherwise choose one of other ways to generate HTML.

4.7.3. For Developers

Run test examples with:

./node_modules/.bin/cucumber.js features/<FEATURE_NAME>.feature

Available tests:

  • basic → basic test results

  • description → scenario description test

  • label → cucumber tags (currently labels are not visible in generated report …​)

  • exception → test throws exception

  • attachments → docStrings and dataTable tests

  • scenarioOutline → scenario outline tests

  • subSteps → steps add sub steps using allure object

or run everything with: ./node_modules/.bin/cucumber.js features/

To check protractor screenshot test install protractor and protractor-cucumber-framework and then run tests: ./node_modules/protractor/bin/protractor miscellaneous/protractorScreenshot/conf.js

To check basic logging run: ./node_modules/.bin/cucumber.js miscellaneous/logging

To check basic configuration run: ./node_modules/.bin/cucumber.js miscellaneous/configuration

To check custom tags run: ./node_modules/.bin/cucumber.js miscellaneous/customTagNames

4.7.4. Release notes

01/09/2016 version 1.0.3

  • added possibility to cancel steps and tests

11/07/2016 version 1.0.2

  • peer dependency for cucumber (>= 1.2.0) added

06/07/2016 version 1.0.1

  • dependencies updated for allure-js-commons, protractor, cucumber and protractor-cucumber-framework

  • fixed cucumber handlers - getPayload will not be available in upcoming cucumber major release

  • updated data table and doc string handling

02/12/2015 version 1.0.0

  • plugin updated to work with cucumber 0.9.1

01/09/2015 version 0.0.1

  • first release

4.8. Cucumber JVM

4.8.1. Allure Cucumber-JVM Plugin

This plugin allows to generate allure xml reports after cucumber-jvm test execution.

Example projects (JUnit and TestNG)

4.8.2. Installation

Maven

Simply add allure-cucumber-jvm plugin as dependency to your project and add it to CucumberOptions:

<project>
...
    <dependencies>
        <dependency>
            <groupId>io.qameta.allure</groupId>
            <artifactId>allure-cucumber-jvm</artifactId>
            <version>2.0-BETA2</version>
        </dependency>
    </dependencies>
        <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.19.1</version>
                <configuration>
                    <testFailureIgnore>false</testFailureIgnore>
                    <argLine>
                        -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
                        -Dcucumber.options="--plugin io.qameta.allure.cucumberjvm.AllureCucumberJvm"
                    </argLine>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>org.aspectj</groupId>
                        <artifactId>aspectjweaver</artifactId>
                        <version>1.8.4</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
</project>

Then execute mvn clean test goal. After tests executed allure JSON files will be
placed in allure-results directory by default. It can be overridden by setting allure.results.directory
system property.

4.8.3. Features

This adapter provides runtime integration allowing conversion of Gherkin dsl features into basic Allure features

Title

Titles for tests and suites are extracted at runtime from .feature files

Description

Feature’s description appears on every scenario

Steps

All scenario steps are automatically translated into allure steps

Attachments

An attachment in Java code is simply a method annotated with @Attachment that returns either a String or byte[], which should be added to the report. You can call this method from the one of the step definition methods or in after/before methods.

@Attachment
public String performedActions(ActionSequence actionSequence) {
    return actionSequence.toString();
}

@Attachment(value = "Page screenshot", type = "image/png")
public byte[] saveScreenshot(byte[] screenShot) {
    return screenShot;
}

If return type in a method annotated with @Attachment differs from String or byte[] we call toString()
on return value to get attachment contents.

You can specify exact MIME type for each attached file using type parameter of @Attachment annotation
like shown above. However, there’s no need to explicitly specify attachment type for all attached files as Allure
by default analyses attachment contents and can determine attachment type automatically. You usually need to
specify attachment type when working with plain text files.

Issues Tracker

To pass issues to report, just add @issue=<ISSUE-NUMBER> on top of Scenario on Feature in your .feature file.
URL template for the issue tracker should be set via allure.link.issue.pattern = https://example.org/{} system
property.

Test Management System

To pass TMS links to report, just add @tmsLink=<TEST-CASE-ID> on top of Scenario on Feature in your .feature file.
URL template for the TMS should be set via allure.link.tms.pattern = https://example.org/{} system property.

Severity

To set severity, add @severity=blocker on top of Scenario on Feature in your .feature file.
If severity has wrong value it will be forced to normal (default).

Supported severity values: blocker, critical, normal, minor, trivial.

Scenario Attributes

Every Feature or Scenario can be annotated by following tags: @flaky, @muted, @known

Before/After

All methods annotated by @import cucumber.api.java.After or @cucumber.api.java.Before annotations
will appear in the report as steps with method names.
If @Before execution fails, the scenario will be marked as skipped.
If @After execution fails, the scenario will be marked as passed, and only After method’s step
will be marked as failed.

Behaviours Mapping

In some development approaches tests are classified by features and stories.
Allure report for cucumber jvm uses information extracted from Feature: section

4.9. Karma

Reporter for the Allure XML format. It allows to make a detailed report

4.9.1. karma-allure-reporter

Install karma-allure-reporter into your project as devDependency

{
  "devDependencies": {
    "karma": "~0.10",
    "karma-allure-reporter": "~1.0.0"
  }
}

You can simple do it by:

npm install karma-allure-reporter --save-dev

4.9.2. Configuration

Add allure into reporters section. Allure-reporter has a single config, it’s a reportDir — result files location relatively to base dir. By default, files save right in the base dir.

// karma.conf.js
module.exports = function(config) {
  config.set({
    reporters: ['progress', 'allure'],

    // the default configuration
    allureReport: {
      reportDir: '',
    }
  });
};

You can pass list of reporters as a CLI argument too:

karma start --reporters allure,dots

4.9.3. API

With allure reporter you get some functions for provide additional info about tests. All functions available as methods of the global allure object.

  • description(description) assign a description to current testcase

  • severity(severity) assign a severity to current testcase. Possible values enumerated as properties, eg. allure.severity.BLOCKER. All securities by descending of their importance:

    • BLOCKER

    • CRITICAL

    • NORMAL

    • MINOR

    • TRIVIAL

  • createStep(name, stepFunction) defines test step. Returns wrapped function which reports about every step calling. Step function can be nested within one another. It is most powerful feature of allure, because it allow to write self-documented tests which report about every its step.

See the docs in core project for more information about these features and their purpose.

4.9.4. Example

There is an example project, where you may look to allure-reporter in action.

For more information about Allure see the allure core project.

For more information about Karma see the Karma homepage.

4.10. Mocha

4.10.1. mocha-allure-reporter

Allure reporter for Mocha framework.

4.10.2. Installation

Assuming that you have mocha installed, install reporter via npm:

npm install mocha-allure-reporter

Then use it as any other mocha reporter:

mocha --reporter mocha-allure-reporter

After running tests you will get raw tests result into allure-results directory. See generator list on how to make a report from raw results.

Also check out mocha-allure-example to see it in action.

4.10.3. Supported options

  • targetDir (string) – directory where test results will be stored

4.10.4. Runtime API

Allure is a test framework which provides more data from tests than usual. Once added mocha-allure-reporter will create global allure object with the following API:

  • allure.createStep(name, stepFn) – define step function. Result of each call of this function will be recorded into report.

  • allure.createAttachement(name, content, [type]) – save attachment to test. If you’re calling this inside step function or during its execution (e.g. asynchronously via promises), attachment will be saved to step function.

    • name (String) - attachment name. Note that it is not then name of the file, actual filename will be generated.

    • content (Buffer|String|Function) – attachment content. If you pass Buffer or String, it will be saved to file immediately. If you are passing Function, you will get decorated function and you can call it several times to trigger attachment. General purpose of the second case is an ability to create utility function to take screenshot. You can define function for you test framework only once and then call it each time you need a screenshot.

    • type (String, optional) – attachment MIME-type. If you omit this argument we’ll try to detect type automatically via file-type library

  • allure.description(description) – set detailed test description, if test name is not enough.

  • allure.severity(severity) – set test severity, one of: blocker, critical, normal, minor, trivial. You can also use constants like allure.SEVERITY.BLOKER.

  • allure.feature(featureName) – assign feature to test

  • allure.story(storyName) – assign user story to test. See documentation for details

  • allure.addArgument(name, value) - provide parameters, which had been used in test. Unlike other languages, javascript test methods usually doesn’t have special arguments (only callbacks), so developers use other way to populate parameters to test. This method is to provide them to Allure

  • allure.addEnvironment(name, value) - save environment value. It is similar to addArgument method, but it is designed to store more verbose data, like HTTP-links to test page or used package version.

4.11. MSTest

MSTestAllureAdapter allows you convert an MSTest trx file to the XMLs from which an Allure report can be generated.

Because MSTest does not have an extension or hook mechanism this adapter cannot run as part of MSTest but instead it converts the resulting trx file to the xml format expected by allure.

It is a .NET/Mono based console application.

4.11.1. Usage

MSTestAllureAdapter.Console.exe <TRX file> [output target dir]

If '[output target dir]' is missing the reslts are saved in the current directory in a folder named 'results'.

$ mono MSTestAllureAdapter.Console.exe sample.trx

This will generate the xml files from which the allure report can be created based upon the 'sample.trx' file.

$ mono MSTestAllureAdapter.Console.exe sample.trx output-xmls

This will generate the xml files from which the allure report can be created in a folder named 'output-xmls' based upon the 'sample.trx' file.

If the target directory does not exists it is created.

To generate a report using allure-cli:

$ allure generate output-xmls -v 1.4.0

4.12. Nose

It is a port of pytest-allure-adaptor for nose framework.

4.12.1. Usage

 nosetests --with-allure --logdir=/path/to/put/results
 nosetests --with-allure --logdir=/path/to/put/results --not-clear-logdir

Option "--not-clear-logdir" is useful with option "--processes" to prevent cleaning of logdr at the end of testing.

4.12.2. Supported features

Attachment

To attach some content to test report:

import nose

def test_foo():
    nose.allure.attach('my attach', 'Hello, World')
Step

To divide a test into steps:

import nose

def test_foo():
    with nose.allure.step('step one'):
        # do stuff

    with nose.allure.step('step two'):
        # do more stuff

Can also be used as decorators. By default step name is generated from method name:

import nose

@nose.allure.step
def make_test_data_foo():
    # do stuff

def test_foo():
    assert make_some_data_foo() is not None

@nose.allure.step('make_some_data_foo')
def make_some_data_bar():
    # do another stuff

def test_bar():
    assert make_some_data_bar() is not None
Environment

You can provide test environment parameters such as report name, browser or test server address to allure test report.

import nose

def test_dummy():
    nose.allure.environment(report='Allure report', browser=u'Firefox')
Severity

Any test, class or module can be marked with different severity:

import nose

class TestBar(object):

    @nose.allure.severity(nose.allure.severity_level.CRITICAL)
    def test_bar(self):
        pass

# custom severity
@nose.allure.severity("hard")
def test_bar(self):
    pass

To run tests with concrete priority:

nosetests my_tests/ --with-allure --logdir=tmp --severity="critical, hard"
Issue

Issues can be set for test.

import nose

@nose.allure.issue('http://jira.lan/browse/ISSUE-1')
def test_foo():
    assert False
Features & Stories

Feature and Story can be set for test.

import nose

@nose.allure.feature('Feature1')
@nose.allure.story('Story1')
def test_minor():
    assert False

class TestBar(object):

    @nose.allure.feature('Feature2')
    @nose.allure.story('Story1')
    def test_bar(self):
        pass

To run tests by Feature or Story:

 nosetests my_tests/ --with-allure --logdir=tmp --feature="Feature1, Feature2"
 nosetests my_tests/ --with-allure --logdir=tmp --feature="Feature1, Feature2" --story="Story1, Story2"

4.13. NUnit

4.13.1. Installation and Usage

  1. Download NUnit 2.6.3 or 2.6.4 from official site;

  2. Download latest release from allure-nunit2 releases for corresponding version (version specified in parentheses);

  3. Unpack binaries to %NUnit_installation_directory%\bin\addins;

  4. NOTE: addin will NOT be visible in Tools → Addins.. because it’s built against .NET 4.0;

  5. In %NUnit_installation_directory%\bin\addins\config.xml specify ABSOLUTE path to any folder (this folder will be created automatically) where xml files will be generated (e.g. <results-path>C:\test-results\AllureResults</results-path> or <results-path>/home/user/test-results/AllureResults</results-path>);

  6. You can also specify in configuration whether you want to take screenshots after failed tests and whether you want to have test output to be written to attachments.

  7. Run your tests with NUnit GUI or nunit-console using .NET 4.0 (e.g. nunit-console YourAssembly.dll /framework=net-4.0);

  8. After all tests finish you’ll see new folder that you specified on step 5 with generated xml files;

4.13.2. How to generate report

This adapter only generates XML files containing information about tests. See wiki section on how to generate report.

4.13.3. What about NUnit 3?

It’s still in alpha-stage, too early to develop an adapter for it. Adapter for NUnit 3 will be located in it’s own repository.

4.13.4. Further reading

4.14. RSpec

Adaptor to use the Allure framework along with the RSpec. See an example project to take a quick tour.

4.14.1. What’s new

See the releases tab.

4.14.2. Setup

Add the dependency to your Gemfile. Choose the version carefully:

  • 0.5.x - for RSpec2.

  • ⇐ 0.6.7 - for RSpec < 3.2.

  • >= 0.6.9 - for RSpec >= 3.2.

 gem 'allure-rspec'

And then include it in your spec_helper.rb:

    RSpec.configure do |c|
      c.include AllureRSpec::Adaptor
    end

4.14.3. Advanced options

You can specify the directory where the Allure test results will appear. By default it would be 'gen/allure-results' within your current directory.

    AllureRSpec.configure do |c|
      c.output_dir = "/whatever/you/like" # default: gen/allure-results
      c.clean_dir = false # clean the output directory first? (default: true)
      c.logging_level = Logger::DEBUG # logging level (default: DEBUG)
    end

4.14.4. Usage examples

describe MySpec, :feature => "Some feature", :severity => :normal do

  before(:step) do |s|
    puts "Before step #{s.current_step}"
  end

  it "should be critical", :story => "First story", :severity => :critical, :testId => 99 do
    "string".should == "string"
  end

  it "should be steps enabled", :story => ["First story", "Second story"], :testId => 31 do |e|

    e.step "step1" do |s|
      s.attach_file "screenshot1", take_screenshot_as_file
    end

    e.step "step2" do
      5.should be > 0
    end

    e.step "step3" do
      0.should == 0
    end

    e.attach_file "screenshot2", take_screenshot_as_file
  end
end

4.15. Scaltest

This adapter allows to retrieve test execution data from [ScalaTest]() framework and convert it to the form suitable for [Allure report generation](https://github.com/allure-framework/allure-core/wiki#generating-report).

4.15.1. Example project

4.15.2. Installation, Configuration and Usage

In order to use this adapter you need to have JDK 1.7+ installed. To enabled adapter simply add the following dependency to build.sbt:

libraryDependencies += "ru.yandex.qatools.allure" % "allure-scalatest_2.10" % "1.4.0-SNAPSHOT"

Then attach AllureReporter in build.sbt:

testOptions in Test ++= Seq(
    Tests.Argument(TestFrameworks.ScalaTest, "-oD"),
    Tests.Argument(TestFrameworks.ScalaTest, "-C", "ru.yandex.qatools.allure.scalatest.AllureReporter")
)

When using this adapter you can encounter the following warning:

[ScalaTest-dispatcher] WARN ru.yandex.qatools.allure.utils.AllureResultsUtils - Can't set "com.sun.xml.bind.marshaller.CharacterEscapeHandler" property to given marshaller
javax.xml.bind.PropertyException: name: com.sun.xml.bind.marshaller.CharacterEscapeHandler value: ru.yandex.qatools.allure.utils.BadXmlCharacterEscapeHandler@5e652b7b
    at javax.xml.bind.helpers.AbstractMarshallerImpl.setProperty(AbstractMarshallerImpl.java:358)
    at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.setProperty(MarshallerImpl.java:527)
    at ru.yandex.qatools.allure.utils.AllureResultsUtils.setPropertySafely(AllureResultsUtils.java:199)
    at ru.yandex.qatools.allure.utils.AllureResultsUtils.marshaller(AllureResultsUtils.java:171)
    at ru.yandex.qatools.allure.utils.AllureResultsUtils.writeTestSuiteResult(AllureResultsUtils.java:148)
    at ru.yandex.qatools.allure.Allure.fire(Allure.java:180)
    at ru.yandex.qatools.allure.scalatest.AllureReporter.testSuiteFinished(AllureReporter.scala:74)
    at ru.yandex.qatools.allure.scalatest.AllureReporter.apply(AllureReporter.scala:46)
    at org.scalatest.DispatchReporter$Propagator$$anonfun$run$1.apply(DispatchReporter.scala:240)
    at org.scalatest.DispatchReporter$Propagator$$anonfun$run$1.apply(DispatchReporter.scala:239)
    at scala.collection.immutable.List.foreach(List.scala:318)
    at org.scalatest.DispatchReporter$Propagator.run(DispatchReporter.scala:239)
    at java.lang.Thread.run(Thread.java:744)

This is related to incompatible JAXB versions used in Allure and Scalatest so you can safely ignore it.

4.15.3. How to generate report

This adapter only generates XML files containing information about tests. See [wiki section] (https://github.com/allure-framework/allure-core/wiki#generating-report) on how to generate report.

4.15.4. Publishing to Sonatype (adapter development)

A publicly available (on public keyserver) GPG key should be present in you default GPG keyring. You need to create sonatype.sbt file in ~/.sbt/<sbt-version>/:

credentials += Credentials("Sonatype Nexus Repository Manager",
                           "oss.sonatype.org",
                           "login",
                           "password")

To publish simply run:

$ sbt publish-signed

4.16. Specs

This adapter allows to retrieve test execution data from Specs framework and convert it to the form suitable for Allure report generation.

4.16.1. Example project

4.16.2. Usage

In order to use this adapter you need to have JDK 1.7+ installed. To enabled adapter simply add the following dependency to build.sbt:

libraryDependencies += "ru.yandex.qatools.allure" % "allure-specs2_2.10" % "1.4.0-SNAPSHOT"

Then attach AllureReporter in build.sbt:

testOptions in Test ++= Seq(
  Tests.Argument(TestFrameworks.Specs2, "notifier", "ru.yandex.qatools.allure.specs2.AllureNotifier")
)

4.17. Spock

Spock Framework sources - https://github.com/spockframework/spock

4.17.1. Spock Framework compatibilities

4.18. ALLURECodeception

This is an official Codeception adapter for Allure Framework.

4.18.1. What is this for?

The main purpose of this adapter is to accumulate information about your tests and write it out to a set of XML files: one for each test class. This adapter only generates XML files containing information about tests. See wiki section on how to generate report.

4.18.2. Example project

4.18.3. Installation and Usage

In order to use this adapter you need to add a new dependency to your composer.json file:

{
    "require": {
        "php": ">=5.4.0",
        "allure-framework/allure-codeception": "~1.1.0"
    }
}

To enable this adapter in Codeception tests simply put it in "enabled" extensions section of codeception.yml:

extensions:
    enabled:
        - Yandex\Allure\Adapter\AllureAdapter
    config:
        Yandex\Allure\Adapter\AllureAdapter:
            deletePreviousResults: false
            outputDirectory: allure-results

deletePreviousResults will clear all .xml files from output directory (this behavior may change to complete cleanup later). It is set to false by default.

outputDirectory is used to store Allure results and will be calculated relatively to Codeception output directory (also known as paths: log in codeception.yml) unless you specify an absolute path. You can traverse up using .. as usual. outputDirectory defaults to allure-results.

To generate report from your favourite terminal, install allure-cli and run following command (assuming you’re in project root and using default configuration):

allure generate --report-version 1.4.5 --report-path tests/_output/allure-report -- tests/_output/allure-results

Report will be generated in tests/_output/allure-report.

4.18.4. Main features

See respective PHPUnit section.

5. Reporting

Once the XML files have been created by the adapter, you can generate an Allure report using one of the following tools

5.1. Commandline

Using Allure command line tool you can generate the report from existing Allure results.

5.1.1. Installation

Allure CLI is a Java application so it’s available for all platforms. You have to manually install Java 1.8 before using Allure CLI

Mac OS

You can install Allure CLI via Homebrew.

$ brew tap qameta/allure
$ brew install allure

After installation you will have allure command available. Read more about Allure Homebrew Formula.

Debian

For Debian-based repositories we provide a PPA so the installation is straightforward:

$ sudo apt-add-repository ppa:yandex-qatools/allure-framework
$ sudo apt-get update
$ sudo apt-get install allure-commandline

Supported distributions are: Trusty and Precise. After installation you will have allure command available. Read more about Allure Debian Package.

Windows and other Unix
  • Download the latest version as zip archive from bintray.

  • Unpack the archive to allure-commandline directory.

  • Navigate to bin directory.

  • Use allure.bat for Windows and allure for other Unix platforms.

  • Add allure to system PATH.

5.1.2. Configuration

To configure the Allure report you should create allure.properties file

allure.properties
allure.issues.tracker.pattern=https://tms/testcase-%s
allure.tests.management.pattern=https://bugtracker/issue-%s

and simply generate the report. By default command line tool looking for config in directory you run the command. You can use ALLURE_CONFIG environment variable to specify the path to configuration.

Usage

There is few commands available.

Generate the report

To generate the report from existing Allure results you can use the following command:

$ allure generate directory-with-results/

The report will be generated to allure-report folder. You can change the destination folder using -o flag:

$ allure generate directory-with-results/ -o directory-with-report

For more information use the allure help generate command.

Open the report

When the report is generated you can open it in your default system browser. Simply run

$ allure report open
Clean the report

If you want to remove the generated report data use allure report clean command.

By default the report commands will looking for the report in allure-results folder. If you are want to use the report from different location you can use -o option.

5.2. Jenkins

5.2.1. Installation

First part of installation guide concerns global installation of Allure plugin and it’s commandline tool. Note that unlike to previous versions Jenkins Allure Plugin since 2.11 does not require to configure Jenkins Content Security Policy properties.

  1. Install the latest version of Allure Plugin from "Plugin Manager" page.

  2. Open Plugin Advanced Settings (at <your_jenkins_host>/pluginManager/advanced).

  3. Click "Check Updates" button on the bottom right corner of the page.

  4. Configure Allure Commandline from "Global Tools Configuration".

Build agents have connection to Maven repository with Allure distribution
  1. Open "Global Tool Configuration".

  2. Find "Allure Commandline" configuration block.

    Find Allure Commandline
  3. Click "Add Allure Commandline" button.

    Install Allure Commandline
  4. Fill the name and choose the version in the "From Maven Central" dropdown.

Downloading and installing Allure from archive
  1. Download latest version of allure-commandline.zip from the github releases page.

  2. Upload downloaded file to any file server. Build agents must have access to the file by url.

  3. Open "Global Tool Configuration". and find "Allure Commandline" configuration block.

  4. Click "Add Allure Commandline" button.

    Install Allure Commandline
  5. Click "Add Installer" and choose "Extract .zip/.tar.gz".

    Install Allure Commandline
  6. Fill the name and download url. Mind that Jenkins will check the provided url immediately and show a warning if it’s not available.

    Install Allure Commanline

5.2.2. Configuration

Job configuration
  1. Open job configuration page.

  2. Ensure that your build generates some data in one of the formats digestible for Allure Commandline tool.

  3. Add Allure Report post build action.

    Select
  4. Configure the Allure Report.

    install allure commanline
Test Management and Bug-Tracking systems integrations

Currently all versions of Allure support setting of url patterns to make direct links to your TMS or bug-tracker available from the report. (Learn more about this integrations link-[here]) It may be done by setting special system properties:

  1. allure.tests.management.pattern property:

    Filling TMS link property
  2. allure.issues.tracker.pattern property:

    Filling bug-tracker link property

in both patterns %s will be substituted for a string value obtained from the label added to test case.

Advanced Options

"Advanced…​" button provides you with several additional settings:

  • jdk to use

  • build policy value

  • include environment flag - currently is not implemented

Allure build step advanced options

5.2.3. Usage

When build is finished a link to Allure report will appear on the build page and also in the build history entries:

Install Allure Commanline

Generated Allure report is stored in the artifacts folder of the build and can be processed the same way as all the other artifacts, or downloaded as .zip archive.

install allure commanline

5.2.4. History files

Allure since version 2 supports history for tests in the report [Learn more about History plugin]. At the every report generation during the build Jenkins Allure Plugin will try to access working directory of the previous build and copy contents of allure-report\history folder to the current report contents. At the moment history entry for test case stores information about up to 5 previous results.

5.2.5. Extensions

Job DSL Plugin

The job-dsl-plugin allows the programmatic creation of projects using a DSL.

// default
publishers {
    allure(['allure-results'])
}

// advanced
publishers {
    allure(['first-results', 'second-results']) {
        jdk('java7')
        commandline('1.4.18')

        buildFor('UNSTABLE')
        includeProperties(true)
        property('allure.issues.tracker.pattern', 'http://tracker.company.com/%s')
        property('allure.tests.management.pattern', 'http://tms.company.com/%s')
    }
}
Pipeline Plugin

To add Allure report generation from pipeline steps one can use Pipeline Syntax builder to generate Allure step code. Note, that commandline parameter points to Allure Commandline installation name to use, if it is not provided, plugin will pick first suitable installation found automatically.

Pipeline step generation

which gives a pipeline script:

node {
// script body

allure([
         includeProperties: false,
         jdk: '',
         properties: [[key: 'allure.issues.tracker.pattern', value: 'http://tracker.company.com/%s']],
         reportBuildPolicy: 'ALWAYS',
         results: [[path: 'target/allure-results'], [path: 'other_target/allure-results']]
         ])
}

To use Allure Report from the pipeline steps one can invoke Allure DSL method as script:

stage('reports') {
    steps {
    script {
            allure([
                    includeProperties: false,
                    jdk: '',
                    properties: [],
                    reportBuildPolicy: 'ALWAYS',
                    results: [[path: 'target/allure-results']]
            ])
    }
    }
}

5.3. TeamCity

5.3.1. Installation

Install Allure TeamCity plugin. Copy the allure-commandline.zip from (latest release to the <TeamCity Data Directory>/plugins/.tools directory. No server restart needed for this step.

5.3.2. Configuration

  1. Open the build configuration settings.

  2. Ensure that your build generates Allure XML files.

  3. Go to Build steps and add the Allure Report build step.

    TeamCity Plugin Install
  4. Configure the step.

    jenkins plugin install

In case you upgrading the Allure TeamCity plugin you need to remove old Allure report generation feature.

5.3.3. Usage

When the build is done you will get Allure Report as a part of build artifacts – simply open the index.html. image::teamcity_plugin_usage.png[jenkins plugin install]

5.4. Bamboo

5.4.1. Installation

  1. Install Allure Plugin from "Plugin Manager Page".

  2. Download the latest version of allure-commandline.zip from github and extract to the desired directory.

  3. Defining a new executable capability with using the extraction directory.

5.4.2. Configuration

  1. Open the build configuration settings.

  2. Ensure that your build generates Allure XML files.

  3. Add Allure task to your job.

    Add Task in Bamboo
  4. Configure task - specify glob pattern to the folder where Allure should search for XML files.

    Task configuration

5.4.3. Usage

When the build is done you will get Allure Report as a part of build artifacts. Сlick on Allure report artifact on the Artifacts tab:

Allure artifact

5.5. Gradle

Gradle Allure Plugin allows you to integrate Allure into spock, testng and junit tests.

5.5.1. Basic usage

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "ru.d10xa:gradle-allure-plugin:0.5.5"
    }
}

apply plugin: 'ru.d10xa.allure'

allure {
    aspectjweaver = true

    // Choose your test framework.
    junit = true
    testNG = false
    spock = false

    // Choose if you're using Geb for web tests
    geb = true
}

5.5.2. Full configuration

allure {
    aspectjweaver = true

    junit = true
    testNG = false
    spock = false

    geb = false

    allureResultsDir = "$buildDir/allure-results"
    allureReportDir = "$buildDir/allure-report"

    allureVersion = "1.4.24.RC3"
    aspectjVersion = "1.8.9"
    allureSpockGebExtensionVersion = "0.2.1"
    allureJunitAspectjAdaptorVersion = "0.1.1"

    clean = true
}

5.5.3. Configuration

  • aspectjweaver (boolean) default false. Adds -javaagent to tests

  • junit (boolean) default false. Enables allure for junit without @RunWith usage. (Adds allure-junit-aspectj-adaptor) based on AspectJ. Require aspectjweaver

  • testNG (boolean) default false. Enables allure for testNG. Require aspectjweaver

  • spock (boolean) default false. Enables allure for spock.

  • geb (boolean) default false. Adds allure-spock-geb dependency for screenshot and html attachments. Specifications must extend geb.spock.GebReportingSpec class

  • allureResultsDir (string) default "$buildDir/allure-results". Test results will be placed to this directory.

  • allureReportDir (string) default "$buildDir/allure-report". Html report will be generated to this directory (if task’s property to not defined)

  • allureVersion (string). Version of allure-bundle and allure-adaptors

  • aspectjVersion (string). Version of org.aspectj:aspectjweaver

  • allureSpockGebExtensionVersion (string). Version of allure-spock-geb

  • allureJunitAspectjAdaptorVersion (string). Version of allure-junit-aspectj-adaptor

  • configuration (string) default 'testCompile'. Apply adaptors to this configuration. For example, you can select the configuration 'compile' and use the adaptor classes in your source code.

  • clean (boolean) default true. Execute appropriate clean tasks before tests and report generation.

5.5.4. Tasks

allureReport

Creates html report for tests.

Add following snippet to build script if you want to create allure report after every test execution

tasks.withType(Test)*.finalizedBy allureReport

If you don’t need this task(for example in child modules) - just delete it

tasks.remove allureReport

Customize task’s parameters

allureReport {
    from(
            "${project(':moduleA').buildDir}/allure-results",
            "${project(':moduleB').buildDir}/my-allure-results",
    )
    to '$buildDir/nice-report'
}

Or create your own task

task customAllureReport(type: ru.d10xa.allure.AllureReportTask){
}
cleanAllureReport

Deletes directory declared in allureReportDir parameter

cleanTest or cleanYourOwnTest

Deletes the test results and allure results created by test or yourOwnTest task

5.6. Maven

5.6.1. Installation

Add allure-maven-plugin to your pom.xml file.

pom.xml
<project>
    ...
    <reporting>
        <excludeDefaults>true</excludeDefaults>
        <plugins>
            <plugin>
                <groupId>ru.yandex.qatools.allure</groupId>
                <artifactId>allure-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </reporting>
    ...
</project>

5.6.2. Configuration

Properties handling

Since 2.5 there is ability to configure report generation. There is few ways to do it:

Directly from source code

Put allure.properties (report.properties for Allure 1.5 or above) to classpath. Both compile class path and test class path are supported.

Or specify the properties in configuration
pom.xml
<configuration>
   <properties>
       <allure.issues.tracker.pattern>http://example.com/%s</allure.issues.tracker.pattern>
   </properties>
</configuration>
Or specify the propertiesFilePath
pom.xml
<configuration>
   <propertiesFilePath>path/to/your/allure.properties</propertiesFilePath>
</configuration>
Results Directory

The path to Allure results directory. In general it is the directory created by allure adaptor and contains allure xml files and attachments. This path can be relative from build directory (for maven it is the target directory) or absolute (absolute only for report mojo). Will be ignored for bulk mojo.

Default value is "allure-results".

System property allure.results.directory.

pom.xml
<plugin>
    <groupId>ru.yandex.qatools.allure</groupId>
    <artifactId>allure-maven-plugin</artifactId>
    <configuration>
        <reportDirectory>allure-report</reportDirectory>
    </configuration>
</plugin>

5.6.3. Usage

The Allure Maven Plugin has three goals:

  • allure:report

  • allure:aggregate

  • allure:bulk

Generate the Allure report as Part of Project Reports
$ mvn site
Generate the Allure Report in a Standalone Fashion

The plugin can also generate the report using its standalone goal:

$ mvn allure:report