| File: tests\Aspire.TestUtilities\TestFeature.cs | Web Access |
| Project: src\tests\Aspire.Playground.Tests\Aspire.Playground.Tests.csproj (Aspire.Playground.Tests) |
// Licensed to the .NET Foundation under one or more agreements. // The .NET Foundation licenses this file to you under the MIT license. namespace Aspire.TestUtilities; [Flags] public enum TestFeature { SSLCertificate = 1 << 0, Playwright = 1 << 1, DevCert = 1 << 2, /// <summary> /// A container runtime is available. Satisfied by either Docker or Podman, so use this for tests /// that just need to run containers. Prefer it over <see cref="Docker"/>. /// </summary> ContainerRuntime = 1 << 3, /// <summary> /// The available container runtime can build images from a Dockerfile. Docker needs the buildx /// plugin for this; Podman builds natively. /// </summary> ContainerImageBuild = 1 << 4, /// <summary> /// Docker specifically is available. Use this only for tests that depend on Docker itself rather /// than on containers in general — for example, ones that bind-mount the Docker socket or invoke /// the <c>docker</c> CLI. Otherwise use <see cref="ContainerRuntime"/>. /// </summary> Docker = 1 << 5, /// <summary> /// The Testcontainers library can reach a container runtime. This implies--but is stricter than--<see cref="ContainerRuntime"/>: /// Testcontainers talks to a Docker-compatible HTTP API rather than /// driving a CLI, so it also needs a socket or named pipe to connect to. Podman does not always /// expose one — Testcontainers 4.x cannot use its Windows named pipe, and on Linux Podman runs /// daemonlessly unless <c>podman system service</c> is running — while DCP-driven container tests /// are perfectly happy on those hosts. Use this for tests backed by a Testcontainers fixture. /// </summary> Testcontainers = 1 << 6 }