Summary

This PR adds Allure.TestingPlatform, a shared MTP integration layer that can be used directly as a standalone Allure adapter or embedded by framework-specific adapters.

The implementation covers runtime registration, configuration discovery, CLI options, result writing, SDK messages and properties, correlation strategies, crash watchdog support, and base classes for custom MTP extensions.

Registration Modes

Allure.TestingPlatform supports two registration modes:

• Standalone: the package acts as the primary Allure adapter for an MTP test project.
• Embedded: another adapter or SDK uses Allure.TestingPlatform as its runtime, writer, lifecycle, and message-processing layer.

Both modes share the same runtime state machine and service registration pipeline.

Standalone Use And Self-Registration

Standalone use is the default package experience. The package ships an MSBuild self-registration hook:

• Allure.TestingPlatform.AllureTestingPlatformBuilderHook
• registered through TestingPlatformBuilderHook metadata in buildTransitive
• enabled by default through Allure_TestingPlatformEnableSelfRegistration=true

When self-registration is enabled, Microsoft.Testing.Platform.MSBuild calls AllureTestingPlatformBuilderHook.AddExtensions, which registers Allure.TestingPlatform in standalone mode with default options.

Self-registration can be disabled in the test project:

<PropertyGroup>
  <Allure_TestingPlatformEnableSelfRegistration>false</Allure_TestingPlatformEnableSelfRegistration>
</PropertyGroup>

When self-registration is disabled, standalone registration can still be performed explicitly:

builder.AddAllure();

or with custom options:

builder.AddAllure(allure =>
{
    allure.UseConfigurationFile("allureConfig.json");
});

Standalone Configuration

Standalone registration is configured through IStandaloneAllureRegistrationContext.

Convenience helpers are available for common cases:

builder.AddAllure(allure =>
{
    allure.UseConfigurationFile("allureConfig.json");
    allure.UseConfiguration(new AllureConfiguration
    {
        Directory = "allure-results"
    });
    allure.UseTypeFormatters(new CustomFormatter());
});

The lower-level configuration API allows replacing the resolved dependencies:

• UseConfiguration(...): provide an AllureConfiguration factory.
• SetIsEnabled(...): decide whether the runtime is enabled.
• UseWriter(...): provide an IAllureResultsWriter.
• UseTypeFormatters(...): provide parameter type formatters.
• DisableHostProcessWatchdog(): disable the crash watchdog through registration.

Default configuration discovery reads, in order:

• an explicit configuration path passed to UseConfigurationFile
• the ALLURE_CONFIG environment variable
• allureConfig.json from the application base directory
• default configuration values

If the MTP result directory is available, the default Allure results directory is placed under it as allure-results. The CLI --allure-results-directory option overrides the discovered configuration directory when the built-in configuration reader is used.

Embedded Configuration

Embedded mode is intended for adapters that already integrate with Microsoft Testing Platform and want to reuse the Allure runtime.

var runtimeReferences = builder.AddEmbeddedAllure(allure =>
{
    allure.UseConfigurationFile("allureConfig.json");
    allure.UseMtpSessionCorrelation();
});

Embedded registration uses IEmbeddedAllureRegistrationContext, which inherits the standalone configuration options and adds SDK-specific hooks:

• UseCorrelation(...): provide a custom ICorrelationStrategy.
• SetSdkEventHandlers(...): subscribe to runtime events.
• UseMtpSessionCorrelation(): correlate messages by MTP session UID.
• UseTestNodeMetadataCorrelation(): correlate messages by test node metadata.
• UseLogger(...): provide the logger used by the adapter.
• UseLifecycle(...): provide an AllureLifecycle.

AddEmbeddedAllure returns an IAllureTestingPlatformRuntimeReferenceRegistry, so the embedding SDK can resolve the runtime reference associated with an MTP IServiceProvider.

CLI Options

The adapter registers an MTP command-line options provider with these options:

--allure on|off
--allure-watchdog on|off
--allure-results-directory <directory>

--allure controls whether the Allure runtime is enabled. It defaults to on.

--allure-watchdog controls the crash watchdog. It defaults to on and overrides the registration-time watchdog setting when supplied.

--allure-results-directory sets the output directory for Allure result files. This is honored by the built-in configuration reader. If a custom configuration factory is supplied, it is up to that factory to honor the option.

Messages And Properties

The SDK exposes MTP data messages that allow embedded adapters to describe Allure lifecycle operations without directly mutating the lifecycle:

• AllureScopeStartMessage, AllureScopeStopMessage, and AllureScopeTestsMessage
• AllureBeforeFixtureStartMessage and AllureAfterFixtureStartMessage
• AllureFixtureUpdateMessage and AllureFixtureStopMessage
• AllureTestUpdateMessage
• base model operation messages for create, update, and remove operations

Messages carry a CorrelationUid and context identifiers such as ScopeContextUid, FixtureContextUid, and TestContextUid. The data consumer uses these identifiers to buffer, route, and apply operations to the correct Allure lifecycle context.

Messages are customized with Allure properties. The property set covers:

• names, full names, descriptions, and HTML descriptions
• status, status details, and exception-derived status
• start, stop, and duration updates
• labels, links, parameters, title path, and default suite labels
• byte-array and file attachments
• reflected test method metadata and argument serialization

This gives framework-specific adapters a narrow public surface for producing Allure results while keeping lifecycle ordering and writer interaction inside Allure.TestingPlatform.

Correlation

Correlation connects MTP messages and Allure SDK messages that belong to the same logical test session. The motivation for using correlation is that the MTP identifier that serves the same purpose (namely, SessionUid) is inaccessible via the extension API in some test frameworks.

The public abstraction is:

public interface ICorrelationStrategy
{
    Task<CorrelationUid?> GetCorrelationAsync(
        IDataProducer dataProducer,
        DataWithSessionUid message,
        CancellationToken cancellationToken);
}

A CorrelationUid is basically an alternative for SessionUid. It's expected to have a 1-1 correlation between these identifiers.

Built-in strategies include:

• TestingPlatformSessionUidCorrelationStrategy: uses the MTP SessionUid.
• TestNodeMetadataCorrelationStrategy: reads a correlation value from TestMetadataProperty with key Allure.TestingPlatform.CorrelationUid attached to a TestNodeUpdateMessage.

Watchdog

The adapter includes AllureTestingPlatformHostProcessWatchdog, an MTP test host process lifetime handler. When enabled, it writes a global Allure error if the test host process exits unexpectedly.

The watchdog is enabled by default. Sometimes, it may cause the test application to behave unexpectedly, e.g., when a nested MTP application is created. Use the registration API to disable it:

builder.AddAllure(allure =>
{
    allure.DisableHostProcessWatchdog();
});

or via the CLI:

--allure-watchdog off

Base Extension Classes

The SDK includes base classes for MTP extensions that need access to the Allure runtime.

AllureTestingPlatformExtension implements the common MTP IExtension plumbing and exposes protected runtime dependencies:

• Logger
• Configuration
• Writer
• TypeFormatters
• Lifecycle
• CorrelationStrategy
• ConfiguredRuntime
• LiveRuntime

Use this base class for extensions that consume an already configured or live runtime.

AllureTestingPlatformRuntimeControllerExtension is for extensions that are responsible for configuring or starting the runtime. It wraps an IAllureTestingPlatformRuntimeController, configures the runtime from IsEnabledAsync, and exposes EnsureRuntimeStarted() for process-lifetime hooks that may need to write results after a crash or other late event.

The built-in data consumer, in-process runtime controller, and host process watchdog are implemented using these runtime abstractions.

Known limitations

Allure.TestingPlatform uses an isolated AllureLifecycle instance and manipulates the context asynchronously relative to test methods. This makes the current implementation of the runtime API unsupported. Fixing it requires decoupling the API from the AllureLifecycle static singleton. This is the subject of a follow-up PR.

Checklist

• Sign Allure CLA
• Provide unit tests