-
Notifications
You must be signed in to change notification settings - Fork 168
Creating Allure Adapter
This page describes the internal details of the development process for Allure adapters, and is intended for developers and contributors.
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.
- 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.
The implementation of Allure events for Java is located in the events directory.
Notifies about a parameter passed to test (name and value).
Notifies about a new attachment (attachment byte stream, name and MIME type).
Notifies about removed attachments. For example, you can remove a screenshot taken during the test run when the test passes.
Notifies about canceled steps. For example, when one step depends on another and it fails, we mark the first one as canceled.
Notifies about failed steps. This means that one or more assertions in the step were false.
Notifies that step execution was finished. Mainly used to save the timestamp.
Notifies that step execution was started. Mainly used to save the timestamp.
The same as StepCanceledEvent but for test cases.
The same as StepFinishedEvent but for test cases.
Notifies about a test case explicitly marked as ignored or not implemented. Suitable for tests that have no assertions (risky tests).
The same as StepStartedEvent but for test cases.
The same as StepFinishedEvent but for test suites.
The same as StepStartedEvent but for test suites.
- aShot - WebDriver Screenshot utility. Take screenshots, crop, prettify, compare.
- HTML Elements - A Java framework that provides easy-to-use interaction with page elements in webpage tests.
- Properties - A Java library for populating beans with system environment properties in a simple and convenient way.
- Perspective - API and shell to orchestrate multiple clouds.