dotnet-testing-advanced-testcontainers-database_skill

Overview

This skill teaches how to use Testcontainers to run containerized database integration tests for SQL Server, PostgreSQL, and MySQL. It focuses on realistic database behavior testing for EF Core and Dapper, covering container lifecycle, migrations, isolation, and container sharing strategies. The guidance is practical, with examples for fixtures, scripts, wait strategies, and cleanup.

How this skill works

The skill shows how to start disposable database containers using Testcontainers builders, obtain connection strings, and wire them into DbContext or Dapper connections. It covers IAsyncLifetime-based fixtures and xUnit CollectionFixture to share containers across test classes. It also demonstrates applying SQL migration scripts, wait strategies, and deterministic teardown to keep tests isolated and repeatable.

When to use it

• You need to test real database behaviors (transactions, locking, stored procedures).
• EF Core InMemory cannot reproduce SQL translation, collation, or constraint behavior.
• You want to run integration tests against SQL Server, PostgreSQL, or MySQL containers.
• You need to test both EF Core and Dapper data access code against the same DB engine.
• You want faster test suites by sharing containers with CollectionFixture.

Best practices

• Use IAsyncLifetime or CollectionFixture to manage container lifecycle and reduce startup overhead.
• Externalize SQL schema and seed scripts under a SqlScripts folder and copy them to output.
• Apply explicit wait strategies (port availability and log messages) before running tests.
• Clean test data in Dispose or per-test teardown following foreign-key order to maintain isolation.
• Prefer Microsoft.Data.SqlClient for SQL Server and proper provider packages for EF Core.

Example use cases

• Verify transactional rollback, concurrency tokens, and locking behavior using a real database container.
• Run EF Core advanced query tests (Include/ThenInclude, AsSplitQuery, AsNoTracking) against PostgreSQL.
• Exercise Dapper QueryMultiple and DynamicParameters for one-to-many mappings in integration tests.
• Share a single SQL Server container across multiple test classes to cut CI time.
• Load and run ordered SQL table creation scripts from test output to set up schema reliably.