testcontainers-integration-tests
.NETのxUnitで、モックの代わりにDockerコンテナ内の本物のデータベースやメッセージキューなどを使って、インフラを含めた統合テストをTestContainersで記述し、より実践的なテストを行うSkill。
📜 元の英語説明(参考)
Write integration tests using TestContainers for .NET with xUnit. Covers infrastructure testing with real databases, message queues, and caches in Docker containers instead of mocks.
🇯🇵 日本人クリエイター向け解説
.NETのxUnitで、モックの代わりにDockerコンテナ内の本物のデータベースやメッセージキューなどを使って、インフラを含めた統合テストをTestContainersで記述し、より実践的なテストを行うSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o testcontainers-integration-tests.zip https://jpskill.com/download/8724.zip && unzip -o testcontainers-integration-tests.zip && rm testcontainers-integration-tests.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8724.zip -OutFile "$d\testcontainers-integration-tests.zip"; Expand-Archive "$d\testcontainers-integration-tests.zip" -DestinationPath $d -Force; ri "$d\testcontainers-integration-tests.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
testcontainers-integration-tests.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
testcontainers-integration-testsフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
TestContainers を用いた統合テスト
この Skill を使用する場面
この Skill は、以下のような場合に使用します。
- 実際のインフラストラクチャ (データベース、キャッシュ、メッセージキュー) を必要とする統合テストを記述する場合
- 実際のデータベースに対してデータアクセス層をテストする場合
- メッセージキューの統合を検証する場合
- Redis のキャッシュ動作をテストする場合
- インフラストラクチャコンポーネントのモックを回避する場合
- テストが本番環境のような環境で動作することを保証する場合
- データベースの移行とスキーマの変更をテストする場合
参照ファイル
- database-patterns.md: SQL Server、PostgreSQL、および移行テストの例
- infrastructure-patterns.md: Redis、RabbitMQ、マルチコンテナネットワーク、コンテナの再利用、および Respawn
コア原則
- モックよりも実際のインフラストラクチャ - モックではなく、コンテナ内の実際のデータベース/サービスを使用します
- テストの分離 - 各テストは、新しいコンテナまたは新しいデータを取得します
- 自動クリーンアップ - TestContainers は、コンテナのライフサイクルとクリーンアップを処理します
- 高速起動 - 同じクラス内のテスト間で、必要に応じてコンテナを再利用します
- CI/CD 互換 - Docker 対応の CI 環境でシームレスに動作します
- ポートのランダム化 - コンテナは、競合を避けるためにランダムなポートを使用します
モックではなく TestContainers を使用する理由
インフラストラクチャのモックの問題点
// BAD: データベースのモック
public class OrderRepositoryTests
{
private readonly Mock<IDbConnection> _mockDb = new();
[Fact]
public async Task GetOrder_ReturnsOrder()
{
// これは実際の SQL の動作、制約、またはパフォーマンスをテストしません
_mockDb.Setup(db => db.QueryAsync<Order>(It.IsAny<string>()))
.ReturnsAsync(new[] { new Order { Id = 1 } });
var repo = new OrderRepository(_mockDb.Object);
var order = await repo.GetOrderAsync(1);
Assert.NotNull(order);
}
}
問題点: 実際の SQL クエリをテストしない、制約/インデックスを見逃す、誤った信頼を与える、SQL 構文エラーをキャッチしない。
より良い方法: 実際のデータベースを使用した TestContainers
// GOOD: 実際のデータベースに対するテスト
public class OrderRepositoryTests : IAsyncLifetime
{
private readonly TestcontainersContainer _dbContainer;
private IDbConnection _connection;
public OrderRepositoryTests()
{
_dbContainer = new TestcontainersBuilder<TestcontainersContainer>()
.WithImage("mcr.microsoft.com/mssql/server:2022-latest")
.WithEnvironment("ACCEPT_EULA", "Y")
.WithEnvironment("SA_PASSWORD", "Your_password123")
.WithPortBinding(1433, true)
.Build();
}
public async Task InitializeAsync()
{
await _dbContainer.StartAsync();
var port = _dbContainer.GetMappedPublicPort(1433);
var connectionString = $"Server=localhost,{port};Database=TestDb;User Id=sa;Password=Your_password123;TrustServerCertificate=true";
_connection = new SqlConnection(connectionString);
await _connection.OpenAsync();
await RunMigrationsAsync(_connection);
}
public async Task DisposeAsync()
{
await _connection.DisposeAsync();
await _dbContainer.DisposeAsync();
}
[Fact]
public async Task GetOrder_WithRealDatabase_ReturnsOrder()
{
await _connection.ExecuteAsync(
"INSERT INTO Orders (Id, CustomerId, Total) VALUES (1, 'CUST1', 100.00)");
var repo = new OrderRepository(_connection);
var order = await repo.GetOrderAsync(1);
Assert.NotNull(order);
Assert.Equal("CUST1", order.CustomerId);
Assert.Equal(100.00m, order.Total);
}
}
SQL Server、PostgreSQL、および移行テストの完全な例については、database-patterns.md を参照してください。
Redis、RabbitMQ、マルチコンテナネットワーク、コンテナの再利用、および Respawn データベースリセットパターンについては、infrastructure-patterns.md を参照してください。
必要な NuGet パッケージ
<ItemGroup>
<PackageReference Include="Testcontainers" Version="*" />
<PackageReference Include="xunit" Version="*" />
<PackageReference Include="xunit.runner.visualstudio" Version="*" />
<!-- Database-specific packages -->
<PackageReference Include="Microsoft.Data.SqlClient" Version="*" />
<PackageReference Include="Npgsql" Version="*" /> <!-- For PostgreSQL -->
<PackageReference Include="MySqlConnector" Version="*" /> <!-- For MySQL -->
<!-- Other infrastructure -->
<PackageReference Include="StackExchange.Redis" Version="*" /> <!-- For Redis -->
<PackageReference Include="RabbitMQ.Client" Version="*" /> <!-- For RabbitMQ -->
</ItemGroup>
ベストプラクティス
- 常に IAsyncLifetime を使用する - 適切な非同期セットアップとティアダウン
- ポートの可用性を待つ -
WaitStrategyを使用して、コンテナが準備できていることを確認します - ランダムポートを使用する - TestContainers にポートを自動的に割り当てさせます
- テスト間でデータをクリーンにする - 新しいコンテナを使用するか、テーブルを切り捨てます
- 可能な場合はコンテナを再利用する - 各テストで新しいコンテナを作成するよりも高速です
- 実際のクエリをテストする - モックをテストするだけでなく、実際の SQL の動作を検証します
- 制約を検証する - 外部キー、一意制約、インデックスをテストします
- トランザクションをテストする - ロールバックとコミットの動作を検証します
- 現実的なデータを使用する - 本番環境のようなデータ量でテストします
- クリーンアップを処理する - 常に
DisposeAsyncでコンテナを破棄します
よくある問題と解決策
コンテナの起動タイムアウト
_container = new TestcontainersBuilder<TestcontainersContainer>()
.WithImage("postgres:latest")
.WithWaitStrategy(Wait.ForUnixContainer()
.UntilPortIsAvailable(5432)
.WithTimeout(TimeSpan.FromMinutes(2)))
.Build();
ポートが既に使用されている
常にランダムポートマッピングを使用してください:
.WithPortBinding(5432, true) // true = ランダムなパブリックポートを割り当てる
コンテナがクリーンアップされない
適切な破棄を保証してください:
public async Task DisposeAsync()
{
await _connection?.DisposeAsync();
await _containe 📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Integration Testing with TestContainers
When to Use This Skill
Use this skill when:
- Writing integration tests that need real infrastructure (databases, caches, message queues)
- Testing data access layers against actual databases
- Verifying message queue integrations
- Testing Redis caching behavior
- Avoiding mocks for infrastructure components
- Ensuring tests work against production-like environments
- Testing database migrations and schema changes
Reference Files
- database-patterns.md: SQL Server, PostgreSQL, and migration testing examples
- infrastructure-patterns.md: Redis, RabbitMQ, multi-container networks, container reuse, and Respawn
Core Principles
- Real Infrastructure Over Mocks - Use actual databases/services in containers, not mocks
- Test Isolation - Each test gets fresh containers or fresh data
- Automatic Cleanup - TestContainers handles container lifecycle and cleanup
- Fast Startup - Reuse containers across tests in the same class when appropriate
- CI/CD Compatible - Works seamlessly in Docker-enabled CI environments
- Port Randomization - Containers use random ports to avoid conflicts
Why TestContainers Over Mocks?
The Problem with Mocking Infrastructure
// BAD: Mocking a database
public class OrderRepositoryTests
{
private readonly Mock<IDbConnection> _mockDb = new();
[Fact]
public async Task GetOrder_ReturnsOrder()
{
// This doesn't test real SQL behavior, constraints, or performance
_mockDb.Setup(db => db.QueryAsync<Order>(It.IsAny<string>()))
.ReturnsAsync(new[] { new Order { Id = 1 } });
var repo = new OrderRepository(_mockDb.Object);
var order = await repo.GetOrderAsync(1);
Assert.NotNull(order);
}
}
Problems: doesn't test actual SQL queries, misses constraints/indexes, gives false confidence, doesn't catch SQL syntax errors.
Better: TestContainers with Real Database
// GOOD: Testing against a real database
public class OrderRepositoryTests : IAsyncLifetime
{
private readonly TestcontainersContainer _dbContainer;
private IDbConnection _connection;
public OrderRepositoryTests()
{
_dbContainer = new TestcontainersBuilder<TestcontainersContainer>()
.WithImage("mcr.microsoft.com/mssql/server:2022-latest")
.WithEnvironment("ACCEPT_EULA", "Y")
.WithEnvironment("SA_PASSWORD", "Your_password123")
.WithPortBinding(1433, true)
.Build();
}
public async Task InitializeAsync()
{
await _dbContainer.StartAsync();
var port = _dbContainer.GetMappedPublicPort(1433);
var connectionString = $"Server=localhost,{port};Database=TestDb;User Id=sa;Password=Your_password123;TrustServerCertificate=true";
_connection = new SqlConnection(connectionString);
await _connection.OpenAsync();
await RunMigrationsAsync(_connection);
}
public async Task DisposeAsync()
{
await _connection.DisposeAsync();
await _dbContainer.DisposeAsync();
}
[Fact]
public async Task GetOrder_WithRealDatabase_ReturnsOrder()
{
await _connection.ExecuteAsync(
"INSERT INTO Orders (Id, CustomerId, Total) VALUES (1, 'CUST1', 100.00)");
var repo = new OrderRepository(_connection);
var order = await repo.GetOrderAsync(1);
Assert.NotNull(order);
Assert.Equal("CUST1", order.CustomerId);
Assert.Equal(100.00m, order.Total);
}
}
See database-patterns.md for complete SQL Server, PostgreSQL, and migration testing examples.
See infrastructure-patterns.md for Redis, RabbitMQ, multi-container networks, container reuse, and Respawn database reset patterns.
Required NuGet Packages
<ItemGroup>
<PackageReference Include="Testcontainers" Version="*" />
<PackageReference Include="xunit" Version="*" />
<PackageReference Include="xunit.runner.visualstudio" Version="*" />
<!-- Database-specific packages -->
<PackageReference Include="Microsoft.Data.SqlClient" Version="*" />
<PackageReference Include="Npgsql" Version="*" /> <!-- For PostgreSQL -->
<PackageReference Include="MySqlConnector" Version="*" /> <!-- For MySQL -->
<!-- Other infrastructure -->
<PackageReference Include="StackExchange.Redis" Version="*" /> <!-- For Redis -->
<PackageReference Include="RabbitMQ.Client" Version="*" /> <!-- For RabbitMQ -->
</ItemGroup>
Best Practices
- Always Use IAsyncLifetime - Proper async setup and teardown
- Wait for Port Availability - Use
WaitStrategyto ensure containers are ready - Use Random Ports - Let TestContainers assign ports automatically
- Clean Data Between Tests - Either use fresh containers or truncate tables
- Reuse Containers When Possible - Faster than creating new ones for each test
- Test Real Queries - Don't just test mocks; verify actual SQL behavior
- Verify Constraints - Test foreign keys, unique constraints, indexes
- Test Transactions - Verify rollback and commit behavior
- Use Realistic Data - Test with production-like data volumes
- Handle Cleanup - Always dispose containers in
DisposeAsync
Common Issues and Solutions
Container Startup Timeout
_container = new TestcontainersBuilder<TestcontainersContainer>()
.WithImage("postgres:latest")
.WithWaitStrategy(Wait.ForUnixContainer()
.UntilPortIsAvailable(5432)
.WithTimeout(TimeSpan.FromMinutes(2)))
.Build();
Port Already in Use
Always use random port mapping:
.WithPortBinding(5432, true) // true = assign random public port
Containers Not Cleaning Up
Ensure proper disposal:
public async Task DisposeAsync()
{
await _connection?.DisposeAsync();
await _container?.DisposeAsync();
}
Tests Fail in CI But Pass Locally
Ensure CI has Docker support:
# GitHub Actions
runs-on: ubuntu-latest # Has Docker pre-installed
CI/CD Integration
GitHub Actions
name: Integration Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup .NET
uses: actions/setup-dotnet@v3
with:
dotnet-version: 9.0.x
- name: Run Integration Tests
run: |
dotnet test tests/YourApp.IntegrationTests \
--filter Category=Integration \
--logger trx
- name: Cleanup Containers
if: always()
run: docker container prune -f
Performance Tips
- Reuse containers - Share fixtures across tests in a collection
- Use Respawn - Reset data without recreating containers
- Parallel execution - TestContainers handles port conflicts automatically
- Use lightweight images - Alpine versions are smaller and faster
- Cache images - Docker will cache pulled images locally