CleanArch.DevKit.Mediator.Results.Testing 1.1.1

CleanArch.DevKit.Mediator.Results.Testing

Assertions fluentes pour Result / Result<T> — style AwesomeAssertions, sans aucune dépendance externe.

Rôle

Fournit une lib d'assertions auto-suffisante pour valider les Result retournés par les handlers/services. Aucune dépendance sur FluentAssertions, AwesomeAssertions ou Shouldly — l'API est inspirée d'AwesomeAssertions (Should(), AndConstraint<T>.And) mais l'implémentation est entièrement contenue dans le package. Compatible avec n'importe quel test runner (xUnit, NUnit, MSTest, TUnit, …) : les assertions échouées lèvent une ResultAssertionException.

Installation

dotnet add package CleanArch.DevKit.Mediator.Results.Testing

Dépend uniquement de CleanArch.DevKit.Mediator.Results.

API

Point d'entrée

using CleanArch.DevKit.Mediator.Results.Testing;

Result result = ...;
Result<Order> typed = ...;

result.Should();     // ResultAssertions
typed.Should();      // ResultAssertions<Order>

Assertions communes (Result et Result<T>)

result.Should().BeSuccess();
result.Should().BeFailure();

result.Should().HaveError<NotFoundError>();        // type d'erreur
result.Should().HaveErrorWithCode("user.email_taken");
result.Should().HaveErrorCount(2);
result.Should().HaveValidationErrorFor("Email");   // ValidationError + propriété

Assertions spécifiques à Result<T>

typed.Should().BeSuccessWithValue(expectedOrder);             // égalité via EqualityComparer<T>.Default
typed.Should().HaveValue(o => o.Id == 42 && o.Total > 0);     // prédicat libre

Chaînage avec .And

Toute assertion retourne un AndConstraint<ResultAssertions> (ou ResultAssertions<T>) qui expose .And :

result.Should()
      .BeFailure()
      .And.HaveError<ValidationError>()
      .And.HaveValidationErrorFor("Email")
      .And.HaveErrorCount(1);

Accès à la valeur ou aux erreurs après assertion

var assertions = result.Should().BeSuccess().And;
var value = assertions.Subject.Value;           // Result<T>.Value (lance si failure)
var errors = result.Should().BeFailure().And.Subject.Errors;

Exemples complets

Handler qui renvoie un succès

[Fact]
public async Task CreateOrder_Valid_ReturnsSuccess()
{
    var result = await sut.Handle(new CreateOrder("Widget"), default);

    result.Should()
          .BeSuccess()
          .And.HaveValue(orderId => orderId > 0);
}

Handler qui renvoie une erreur typée

[Fact]
public async Task CreateUser_DuplicateEmail_ReturnsConflict()
{
    repo.Setup("alice@example.com");
    var result = await sut.Handle(new CreateUser("alice@example.com"), default);

    result.Should()
          .BeFailure()
          .And.HaveError<ConflictError>()
          .And.HaveErrorWithCode("user.email_taken");
}

Validation

[Fact]
public async Task CreateUser_InvalidEmail_ReturnsValidationError()
{
    var result = await sut.Handle(new CreateUser("not-an-email"), default);

    result.Should()
          .BeFailure()
          .And.HaveError<ValidationError>()
          .And.HaveValidationErrorFor("Email");
}

Échecs

Quand une assertion échoue, une ResultAssertionException est levée avec un message descriptif :

Expected result to be successful, but it failed with 1 error(s): [user.email_taken] Email already taken.
Expected result to contain an error of type 'NotFoundError', but found: ConflictError.
Expected result to have 3 error(s), but found 1.
Expected validation error for property 'Name', but found failures for: 'Email'.

Le runner (xUnit/NUnit/MSTest/TUnit) capture cette exception comme un échec de test.

Limites

• Pas de paramètre because — l'API ne prend pas de message contextuel (...BeSuccess("because ...")) pour rester simple. L'exception est généralement suffisamment explicite.
• Pas de .Which — pas de drill-into automatique vers la valeur ou les erreurs. Utiliser .And.Subject pour récupérer le Result sous-jacent.
• Pas d'égalité personnalisée — BeSuccessWithValue utilise EqualityComparer<T>.Default. Pour des comparaisons plus riches, utiliser HaveValue(predicate).