🔗 Integration Tests

Full HTTP-level tests that exercise the entire ASP.NET Core pipeline — middleware, controllers, validation, EF Core, encryption — against a real (in-process) SQLite database.

Running

1
dotnet test tests/Grimoire.IntegrationTests

Expected output: 50 tests, ~10 seconds.

How it works

Integration tests use WebApplicationFactory<Program> from Microsoft.AspNetCore.Mvc.Testing. This starts the real ASP.NET Core application in-process, pointing at a unique temporary SQLite file per test class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public sealed class GrimoireWebApplicationFactory : WebApplicationFactory<Program>, IAsyncLifetime
{
    private readonly string _dbPath =
        Path.Combine(Path.GetTempPath(), $"grimoire-test-{Guid.NewGuid():N}.db");

    protected override void ConfigureWebHost(IWebHostBuilder builder)
    {
        builder.UseEnvironment("Testing");
        builder.ConfigureAppConfiguration((_, config) =>
        {
            config.AddInMemoryCollection(new Dictionary<string, string?>
            {
                ["ConnectionStrings:Default"] = $"Data Source={_dbPath}",
                ["Management:AdminApiKey"]    = AdminKey,
                ["Encryption:MasterKey"]      = MasterKey,
                ["Cors:AllowedOrigins:0"]     = "http://localhost:5173"
            });
        });
    }
}

Key properties:

• Each test class gets its own factory (via IClassFixture<GrimoireWebApplicationFactory>)
• The factory creates a fresh temp SQLite file, runs EF Core migrations, then deletes the file on dispose
• Tests within a class run sequentially against the shared factory — they share state
• Tests across different classes run in parallel — they are fully isolated

Test suites

AuthenticationTests (6 tests)

Verifies that the middleware correctly guards endpoints:

Management/ApplicationsTests (9 tests)

Management/EnvironmentsTests (6 tests)

Covers list, create, duplicate 409, delete, and not-found scenarios for environments.

Management/SecretsTests (8 tests)

Covers list, create, duplicate 409, set values, nonexistent environment 404, version history, multiple versions, and delete.

Management/ConfigurationsTests (6 tests)

Covers list, create, duplicate 409, update, delete, and nonexistent-environment 404.

Consumer/ConsumerSecretsTests (7 tests)

Consumer/ConsumerConfigurationsTests (5 tests)

Covers get-all with label, get-all empty, get-by-key 200, get-by-key 404, and unknown-env 404.

Test helpers

TestHelpers.cs contains shared utilities used across all management tests:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Unique names to prevent inter-test conflicts within a shared factory
public static string UniqueName(string prefix = "test") =>
    $"{prefix}-{Guid.NewGuid():N}"[..20];

// Create an application and return (slug, apiKey)
public static async Task<(string slug, string apiKey)> CreateApplicationAsync(
    HttpClient mgmtClient, string? name = null);

// Create an environment and return its slug
public static async Task<string> CreateEnvironmentAsync(
    HttpClient mgmtClient, string appSlug, string envName);

// Create a secret with a value set for an environment
public static async Task CreateSecretWithValueAsync(
    HttpClient mgmtClient, string appSlug, string secretName,
    string envSlug, string value);

Why WebApplicationFactory not mocks?

Using WebApplicationFactory with a real SQLite database ensures that:

1. Middleware is tested — auth, exception handling, request logging all run
2. EF Core queries are tested — including subtle translation differences between in-memory and SQLite
3. FluentValidation is tested — through the full filter pipeline, not in isolation
4. The integration between layers is tested — controllers, repositories, encryption, all together

Mocking at any of these layers would produce tests that pass locally but miss real integration failures.