xunit
xUnitフレームワークを使用して、30個のテストプロジェクト全体にわたるユニットテストを作成できます。以下のような場合にご利用ください:新しいテストの作成、テストカバレッジの追加、統合テストの作成、テストフィクスチャのセットアップ、またはテスト失敗のデバッグを行う際に使用します。
description の原文を見る
Writes unit tests with xUnit framework across 30 test projects. Use when: writing new tests, adding test coverage, creating integration tests, setting up test fixtures, or debugging test failures.
SKILL.md 本文
xUnit スキル
xUnit はテストフレームワークとして使用します。テストは読みやすいアサーションに Shouldly を、モッキングに Nsubstitute を使用します。すべてのテストは厳密な MethodName_Scenario_ExpectedBehavior ネーミングに従います。
クイックスタート
ユニットテスト構造
public class WalletManagerTests
{
private readonly Mock<IRepository<Wallet>> _mockRepository;
private readonly WalletManager _sut;
public WalletManagerTests()
{
_mockRepository = new Mock<IRepository<Wallet>>();
_sut = new WalletManager(_mockRepository.Object);
}
[Fact]
public async Task CreateAsync_ValidWallet_ReturnsSuccess()
{
// Arrange
var wallet = new Wallet { Name = "Test" };
_mockRepository.Setup(r => r.AddAsync(wallet)).ReturnsAsync(wallet);
// Act
var result = await _sut.CreateAsync(wallet);
// Assert
result.IsSuccess.Should().BeTrue();
result.Value.Should().Be(wallet);
}
}
InlineData を使用したセオリー
[Theory]
[InlineData(12)]
[InlineData(15)]
[InlineData(18)]
[InlineData(21)]
[InlineData(24)]
public void GenerateMnemonic_ValidWordCount_ReturnsCorrectLength(int wordCount)
{
var result = _keyManager.GenerateMnemonic(wordCount);
result.IsSuccess.Should().BeTrue();
result.Value!.Split(' ').Should().HaveCount(wordCount);
}
主要な概念
| 概念 | 用途 | 例 |
|---|---|---|
[Fact] | 単一のテストケース | [Fact] public void Method_Test() {} |
[Theory] | パラメータ化テスト | [Theory] [InlineData(1)] public void Method(int x) {} |
IClassFixture<T> | クラス単位の共有状態 | class Tests : IClassFixture<DbFixture> |
ICollectionFixture<T> | クラス間の共有状態 | [Collection("Db")] class Tests |
IAsyncLifetime | 非同期のセットアップ/ティアダウン | Task InitializeAsync(), Task DisposeAsync() |
一般的なパターン
例外テスト
[Fact]
public void Constructor_NullRepository_ThrowsArgumentNullException()
{
var act = () => new WalletManager(null!);
act.Should().Throw<ArgumentNullException>()
.WithParameterName("repository");
}
[Fact]
public async Task ProcessAsync_InvalidData_ThrowsWithMessage()
{
var exception = await Assert.ThrowsAsync<InvalidOperationException>(
() => _processor.ProcessAsync(invalidContext));
exception.Message.Should().Contain("validation failed");
}
非同期テストパターン
[Fact]
public async Task ExecuteAsync_ValidBlueprint_CompletesSuccessfully()
{
// Arrange
var blueprint = CreateTestBlueprint();
// Act
var result = await _engine.ExecuteAsync(blueprint);
// Assert
result.Success.Should().BeTrue();
result.ProcessedData.Should().ContainKey("output");
}
関連項目
patterns- テストパターンとアンチパターンworkflows- テストワークフローとフィクスチャ
関連スキル
- dotnet-testing-nsubstitute-mocking スキルを参照して、依存関係のモッキングについて確認してください
- entity-framework スキルを参照して、InMemory プロバイダーを使用したデータベーステストについて確認してください
ドキュメンテーションリソース
Context7 で最新の xUnit ドキュメンテーションを取得します。
Context7 の使用方法:
mcp__context7__resolve-library-idを使用して "xunit" を検索します- 解決されたライブラリ ID を使用して
mcp__context7__query-docsでクエリを実行します
ライブラリ ID: /xunit/xunit.net (875 個のコードスニペット、高評価)
推奨クエリ:
- "xUnit Theory InlineData patterns"
- "IClassFixture ICollectionFixture shared context"
- "IAsyncLifetime async setup teardown"
- "xUnit parallel test execution configuration"
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- BridgingIT-GmbH
- ライセンス
- MIT
- 最終更新
- 2026/5/5
Source: https://github.com/BridgingIT-GmbH/bITdevKit / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。