Testing Overview

Every module generated by Modulus includes three dedicated test projects. The scaffolded test projects come pre-configured with the right packages, a clean folder structure, and a baseline set of architecture tests -- you can start writing tests immediately after running modulus add-module.

Test Project Types

Project	Suffix	Purpose
Unit Tests	Tests.Unit	Test handlers, validators, and domain logic in isolation
Integration Tests	Tests.Integration	Test endpoints and data access with real infrastructure
Architecture Tests	Tests.Architecture	Enforce layer dependency rules and coding conventions

Project Naming Convention

Test projects follow the pattern {SolutionName}.Modules.{ModuleName}.Tests.{Type}:

tests/Modules/Catalog/
├── EShop.Modules.Catalog.Tests.Unit/
├── EShop.Modules.Catalog.Tests.Integration/
└── EShop.Modules.Catalog.Tests.Architecture/

Packages

All test projects are scaffolded with the following packages:

Package	Purpose
xunit	Test framework
xunit.runner.visualstudio	Visual Studio / CLI test runner
Microsoft.NET.Test.Sdk	.NET test host
Shouldly	Fluent assertion library
NSubstitute	Mocking framework

Architecture test projects additionally include:

Package	Purpose
NetArchTest.Rules	Fluent API for enforcing architectural constraints

Integration test projects additionally include:

Package	Purpose
Microsoft.AspNetCore.Mvc.Testing	WebApplicationFactory for hosting the app in tests
Testcontainers.PostgreSql	Docker-based PostgreSQL for test isolation

Running Tests

Run all tests from the solution root:

dotnet test

Run tests for a specific module:

dotnet test tests/Modules/Catalog/

Run only architecture tests:

dotnet test --filter "FullyQualifiedName~Tests.Architecture"

Run only unit tests:

dotnet test --filter "FullyQualifiedName~Tests.Unit"

Run tests in CI

The scaffolded GitHub Actions workflow runs dotnet test on every push and pull request. Architecture tests catch dependency violations before they reach production. See Contributing for CI details.

Test Organization

Tests within each project are organized to mirror the module's structure:

EShop.Modules.Catalog.Tests.Unit/
├── Products/
│   ├── Commands/
│   │   └── CreateProductHandlerTests.cs
│   ├── Queries/
│   │   └── GetProductByIdHandlerTests.cs
│   └── Validators/
│       └── CreateProductValidatorTests.cs
└── Domain/
    └── ProductTests.cs

This convention makes it easy to find the test for any given class. The test class name mirrors the class under test with a Tests suffix.

What's Next

Dive into the specific testing guides:

• Architecture Tests -- Enforce layer dependency rules with NetArchTest
• Unit Testing -- Test handlers, validators, and domain logic in isolation
• Integration Testing -- Test endpoints end-to-end with WebApplicationFactory