Module 7

Changelog — V0.0.1

• Création du deck sur les tests unitaires, le mocking, AAA et l'introduction au TDD.

Pyramide de test orientée C#

Ce qu'on veut vraiment tester

• Les invariants du domaine.
• Les règles de décision de l'application.
• Les intégrations critiques avec la persistence ou les API externes.
• Pas les getters triviaux, ni le framework à votre place.

Le pattern AAA

[Fact]
public async Task ReserveAsync_ShouldRejectOverlap_WhenSlotAlreadyTaken()
{
    var repository = new InMemoryReservationRepository(existingReservation);
    var handler = new ReserveResourceHandler(repository, new FakeUnitOfWork(), new FakeClock());

    await Assert.ThrowsAsync<ResourceAlreadyReservedException>(() =>
        handler.HandleAsync(command, CancellationToken.None));
}

• Arrange: contexte maîtrisé.
• Act: une action lisible.
• Assert: une attente précise.

Mocking raisonné

• Moq ou NSubstitute pour isoler des dépendances externes.
• Un mock valide une collaboration, pas une implémentation interne.
• Trop de mocks signalent souvent une conception trop couplée.

TDD en boucle courte

• Red: écrire un test qui échoue pour une raison utile.
• Green: produire l'implémentation minimale.
• Refactor: nettoyer sans casser le comportement.

Le TDD n'est pas une religion, c'est une stratégie de feedback.

Organisation du dossier tests/

tests/
  Booking.Domain.Tests/
    ReservationTests.cs
  Booking.Application.Tests/
    ReserveResourceHandlerTests.cs
  Booking.Infrastructure.Tests/
    EfReservationRepositoryTests.cs

• Le nom du projet doit indiquer clairement la couche testée.

Signal de qualité attendu

• Les tests échouent vite et lisiblement.
• La logique métier reste testable sans base réelle.
• Les scénarios de non-régression sont identifiés tôt.