Skip to content
This repository has been archived by the owner on Jan 14, 2019. It is now read-only.

Creating Allure Adapter

Ivan Krutov edited this page May 23, 2014 · 8 revisions

This page describes internal details of Allure adapters developments process and is mainly aimed to developers and contributors.

Adapter Development Considerations

Two layer approach

With 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 Allure adapter for any test framework and any programming language should consist of two main layers:

  • Events API. Should contain the implementation of core Allure events and the logic of saving information about risen events to XML. See below for events list.
  • Test framework API. Should contain logic which handles events of concrete test framework and maps them to generic Allure events. Right now this approach is used with Java-based test frameworks. We already provide events API in allure-java-commons module and simply use it in such adapters as JUnit and TestNG adapters. This is why adapter modules only contain framework-specific code.

Output files conventions

  • Every XML file should be named like the following: -testsuite.xml, where is a universally unique identifier.
  • Every XML files should be valid when checked with Allure schema.
  • Allure adapter output result should store not only XML files with information about tests but also copies of all attached files.
  • Every attachment file should be like the following: -attachment., where is file contents cryptographic hash sum (e.g. MD5, SHA1, Whirlpool and so on), - file extension corresponding to the MIME type in 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 https://github.com/allure-framework/allure-core/tree/master/allure-java-commons/src/main/java/ru/yandex/qatools/allure/events.

AddParameterEvent

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

MakeAttachmentEvent

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

RemoveAttachmentsEvent

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

StepCanceledEvent

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

StepFailureEvent

Notify about failed steps. That means that one or more of assertions in the step were false.

StepFinishedEvent

Notify that step execution was finished. Mainly used to save timestamp.

StepStartedEvent

Notify that step execution was started. Mainly used to save timestamp.

TestCaseCanceledEvent

The same as StepCanceledEvent but for test cases.

TestCaseFinishedEvent

The same as StepFinishedEvent but for test cases.

TestCasePendingEvent

Notify about test case explicitly marked as ignored or not implemented. Suitable for tests having 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.