Creating Allure Adapter - allure-framework/allure1 GitHub Wiki

This page describes the internal details of the development process for Allure adapters, and is intended for developers and contributors.

Adapter Development Considerations

Two-layer Approach

With the existing diversity of mainstream programming languages and test frameworks, it's very important to follow the same approach when implementing Allure adapters. That's why we're sure that any implementation of an Allure adapter for any test framework and any programming language should consist of two main layers:

  • Language API. Should contain an implementation of core Allure events and logic that saves information about test events to XML (see the list of events below). The language API should be implemented once for every programming language.
  • Test framework API. Should contain logic that handles events of a concrete test framework and maps them to generic Allure events. Right now this approach is used with Java-based test frameworks. We already provide an events API in the allure-java-commons module and use it in adapters, such as the JUnit and TestNG adapters. This is why adapter modules only contain framework-specific code.

Output File Conventions

  • Every XML file should be named like this: {UUID}-testsuite.xml, where {UUID} is a universally unique identifier.
  • Every XML file should be valid when checked with the Allure schema.
  • The output result of an Allure adapter should store not only XML files with information about tests, but also copies of all attached files.
  • Every attachment file should be named like this: {HASH-SUM}-attachment.{EXT}, where {HASH-SUM} is the cryptographic hash sum of the file contents (e.g. MD5, SHA1, Whirlpool and so on), {EXT} is the file extension corresponding to the MIME type in the XML file. We require cryptographic hash sums in order to avoid storing files with duplicate content.

Allure Events

The implementation of Allure events for Java is located in the events directory.

AddParameterEvent

Notifies about a parameter passed to test (name and value).

MakeAttachmentEvent

Notifies about a new attachment (attachment byte stream, name and MIME type).

RemoveAttachmentsEvent

Notifies about removed attachments. For example, you can remove a screenshot taken during the test run when the test passes.

StepCanceledEvent

Notifies about canceled steps. For example, when one step depends on another and it fails, we mark the first one as canceled.

StepFailureEvent

Notifies about failed steps. This means that one or more assertions in the step were false.

StepFinishedEvent

Notifies that step execution was finished. Mainly used to save the timestamp.

StepStartedEvent

Notifies that step execution was started. Mainly used to save the timestamp.

TestCaseCanceledEvent

The same as StepCanceledEvent but for test cases.

TestCaseFinishedEvent

The same as StepFinishedEvent but for test cases.

TestCasePendingEvent

Notifies about a test case explicitly marked as ignored or not implemented. Suitable for tests that have no assertions (risky tests).

TestCaseStartedEvent

The same as StepStartedEvent but for test cases.

TestSuiteFinishedEvent

The same as StepFinishedEvent but for test suites.

TestSuiteStartedEvent

The same as StepStartedEvent but for test suites.