Tests

Structure des tests, frameworks utilises, conventions et guide d'execution des tests pour Place API.

Tests

Vue d'ensemble

Place API utilise une strategie de test a deux niveaux : tests unitaires et tests d'integration. Les tests sont executes en serie pour garantir la coherence des donnees.

Frameworks

Framework	Usage
xUnit	Framework de test principal
FluentAssertions	Assertions lisibles et expressives
NSubstitute	Mocking/substitution de dependances
Testcontainers	PostgreSQL ephemere pour les tests d'integration
Respawn	Reinitialisation de la base entre les tests

Structure des projets de test

src/Modules/
├── Identity/
│   └── tests/
│       ├── UnitTest/           # Tests unitaires Identity
│       │   ├── Admin/
│       │   ├── Auth/
│       │   ├── Auditing/
│       │   ├── BackgroundJobs/
│       │   ├── Core/
│       │   ├── Infrastructure/
│       │   ├── Models/
│       │   ├── PersistMessage/
│       │   ├── Security/
│       │   ├── Services/
│       │   └── Web/
│       └── IntegrationTest/    # Tests d'integration Identity
│           ├── Admin/
│           ├── Auth/
│           ├── Auditing/
│           ├── Contracts/
│           ├── Fakes/
│           ├── Infrastructure/
│           └── Sessions/
├── Audit/
│   └── tests/
│       └── UnitTest/           # Tests unitaires Audit
│           ├── Hubs/
│           └── Services/
└── Messaging/
    └── tests/
        ├── UnitTest/           # Tests unitaires Messaging
        │   └── Infrastructure/
        └── IntegrationTest/    # Tests d'integration Messaging
            └── Infrastructure/

Tests unitaires

Couverture par module

Identity (UnitTest)

Dossier	Fichiers de test	Description
`Admin/`	`DeactivateUserCommandHandlerTests`	Logique de desactivation utilisateur
`Auth/`	`LoginCommandHandlerTests`, `ForgotPasswordCommandHandlerTests`, `ChangePasswordCommandHandlerTests`, `UserRegistrationServiceTests`, `TokenServiceTests`, `SocialLoginCommandHandlerTests`, `LinkedAccountsTests`, `UserSessionTests`, `HashedTokenTests`, `IpAddressValueTests`, `OtpCodeTests`, `DeviceInfoProviderTests`, `RequiredPermissionAuthorizationHandlerTests`	Logique d'authentification et sessions
`Auditing/`	`AuditCommandBehaviorTests`, `AuditEmitterOutboxTests`, `AuditHttpMiddlewareTests`, `AuditMaskingServiceTests`, `EntityChangeAuditSaveChangesInterceptorTests`, `HttpAuditContextProviderTests`	Pipeline d'audit
`BackgroundJobs/`	`HangfireBootstrapTests`	Demarrage des jobs Hangfire
`Core/`	`EventDispatcherTests`	Dispatch des evenements domaine
`Infrastructure/`	`RateLimitHeaderWriterTests`, `RateLimitPartitionKeyBuilderTests`, `RateLimitingOptionsValidatorTests`	Rate limiting
`Models/`	`PasswordHistoryTests`, `UserEntityTests`	Logique des entites domaine
`PersistMessage/`	`OutboxDispatchRecurringJobTests`	Outbox pattern
`Security/`	`InputValidationSecurityTests`	Validation des entrees
`Services/`	`EmailMaskerTests`, `GroupRoleServiceTests`, `PasswordExpiryServiceTests`, `PermissionServiceTests`	Services metier
`Web/`	`CorrelationExtensionsTests`, `CurrentUserServiceTests`, `ExceptionTests`, `ForwardedHeadersTrustOptionsTests`, `RequestContextProviderTests`, `ValidationErrorTests`	Couche web

Audit (UnitTest)

Fichier	Description
`AuditHubTests`	Connexion/deconnexion du hub SignalR
`AuditLogWriterTests`	Ecriture des logs d'audit

Messaging (UnitTest)

Fichier	Description
`SnsSmsSenderTests`	Envoi SMS via AWS SNS

Convention de nommage

Les tests suivent la convention :

{Methode}_{Scenario}_{ResultatAttendu}

Exemples :

Login_WithValidCredentials_ReturnsTokens
Login_WithInvalidPassword_ReturnsUnauthorized
Register_WithExistingEmail_ReturnsConflict
Revoke_WithNonExistentSession_ReturnsFalse

Tests d'integration

Infrastructure

Les tests d'integration utilisent Testcontainers pour demarrer une instance PostgreSQL ephemere dans Docker. Docker doit etre en cours d'execution pour lancer les tests d'integration.

Base de test

Chaque module d'integration definit une classe de base :

IdentityIntegrationTestBase : Configure le WebApplicationFactory, les fakes de services, et le seeder de donnees de test.
MessagingIntegrationTestBase : Configuration similaire pour le module Messaging.

Reinitialisation des donnees

Respawn est utilise pour reinitialiser la base de donnees entre chaque test, garantissant l'isolation.

Couverture par module

Identity (IntegrationTest)

Dossier	Fichiers de test	Description
`Auth/`	`LoginTests`, `RegisterNewUserTests`, `LogoutTests`, `RefreshTokenTests`, `ChangePasswordTests`, `ForgotPasswordTests`, `ResetPasswordTests`, `VerifyOtpTests`, `ResendOtpTests`, `SocialLoginTests`, `LinkedAccountsTests`, `LoginSecurityTests`	Flux d'authentification complets
`Admin/`	`AdminUserManagementTests`	Gestion admin des utilisateurs
`Sessions/`	`SessionManagementTests`	Gestion des sessions utilisateur
`Auditing/`	`AuditAdminParityIntegrationTests`, `EntityChangeAuditIntegrationTests`, `OutboxHangfireAuditIntegrationTests`	Integration avec le module Audit
`Infrastructure/`	`ProblemDetailsIntegrationTests`, `RateLimitingIntegrationTests`, `RbacPermissionsIntegrationTests`, `StubServiceSecurityTests`, `UserModelPersistenceTests`	Infrastructure transverse

Messaging (IntegrationTest)

Fichier	Description
`SmsSenderRegistrationTests`	Enregistrement correct du service SMS

Fakes et stubs

Classe	Description
`FakeRegisterNewUserCommand`	Commande d'enregistrement de test
`FakeSocialAuthProvider`	Provider d'authentification sociale factice
`IdentityTestDataSeeder`	Seeder de donnees de test

Execution des tests

Tous les tests

dotnet test

Tests par module

# Tests unitaires Identity
dotnet test src/Modules/Identity/tests/UnitTest/Unit.Test.csproj

# Tests d'integration Identity
dotnet test src/Modules/Identity/tests/IntegrationTest/Integration.Test.csproj

# Tests unitaires Audit
dotnet test src/Modules/Audit/tests/UnitTest/Audit.Unit.Test.csproj

# Tests unitaires Messaging
dotnet test src/Modules/Messaging/tests/UnitTest/Messaging.Unit.Test.csproj

# Tests d'integration Messaging
dotnet test src/Modules/Messaging/tests/IntegrationTest/Messaging.Integration.Test.csproj

Execution en CI

La CI execute les tests via Nuke :

./build.cmd Compile UnitTests IntegrationTests

Les resultats sont publies comme artefacts GitHub Actions.

Les tests sont configures pour s'executer en serie (parallelizeAssembly: false) pour eviter les conflits d'acces aux donnees entre tests d'integration. Cela est configure via les fichiers xunit.runner.json ou les attributs d'assembly.

Tests d'architecture

Bien qu'il n'y ait pas encore de projet Architecture.Tests dedie, le plan de migration prevoit des tests d'architecture pour enforcer :

L'isolation des modules (pas de references directes entre modules internes)
La separation des couches (le domaine ne depend pas de l'infrastructure)
L'utilisation correcte des Contracts comme seul point de communication inter-modules

Exemple de test d'architecture prevu :

[Fact]
public void IdentityModule_ShouldNotReference_AuditModule_Internals()
{
    var result = Types.InAssembly(typeof(IdentityContext).Assembly)
        .ShouldNot()
        .HaveDependencyOn("Audit")
        .GetResult();
    result.IsSuccessful.Should().BeTrue();
}

Bonnes pratiques

Toujours executer les tests avant de pousser (les tests d'integration requierent Docker).
Utiliser la convention de nommage {Method}_{Scenario}_{ExpectedResult}.
Isoler les tests -- chaque test doit etre independant grace a Respawn.
Mocker les dependances externes (SMTP, SNS) dans les tests unitaires avec NSubstitute.
Ne pas mocker le DbContext dans les tests d'integration -- utiliser Testcontainers.