Test HTTP command error responses through real endpoints
メンテナーはふだん 7 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 58/100
調査の方向性
Start with ResultExtensions.cs and the existing ASP.NET Core test application; trace the separate minimal-API and controller command mappings. Add hosted HTTP tests for each listed command outcome, then run the affected endpoint tests and collect focused coverage. Done means both mappings assert status, response body, and problem-details content type without checking full stack traces.
索引モデルが issue の本文から書いたものです。
説明
Problem
The HTTP result-mapping code has approximately 24% line coverage in the October 5, 2026 .NET 10 coverage run. Most error-response paths are untested. These paths define the status codes and problem-details bodies that API clients rely on. You can view a test coverage report I generated here: index.html
Source: ResultExtensions.cs.
Proposed tests
Send HTTP requests to test endpoints backed by command services that produce each outcome:
| Command outcome | Expected response |
|---|---|
| Success | HTTP 200 with the expected result body |
| Domain validation failure | HTTP 400 with domain validation details |
| Missing aggregate | HTTP 404 with problem details |
| Optimistic concurrency conflict | HTTP 409 with problem details |
| Unexpected failure | HTTP 500 with problem details |
Cover both minimal-API and controller command mappings, since they use separate result-conversion paths. Assert the response content type and stable problem-details fields, including domain errors where applicable.
Acceptance criteria
- Each outcome is exercised through an HTTP request to a hosted test application.
- Both minimal-API and controller mappings are covered.
- Assertions verify status codes and response bodies, rather than only whether requests complete.
- Error responses use the expected problem-details content type and structure.
- Tests avoid brittle comparisons of full exception stack traces.
- No direct tests of
ResultExtensions, external database, or Docker container are required.
Validation
Extend the existing ASP.NET Core test application and run the affected endpoint tests. Collect focused coverage for the HTTP result-mapping paths; do not rerun unrelated provider suites.
- 主要言語
- C#
- スター
- 512
- フォーク
- 99
- 平均マージ
- 5日 6時間
- マージ済み PR（30日）
- 5
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Eventuous/eventuous のほかの issue
-
MongoDB integration tests fail on newer GitHub Actions runner kernels対応中かも @nmummau が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
Eventuous/eventuous#626 · コメント 2 件 ·
メンテナーはふだん 7 日以内に返信
-
`dotnet format style --verify-no-changes` fails with naming violations and unnecessary imports対応中かも @nmummau が 2 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
Eventuous/eventuous#624 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
Eventuous/eventuous#627 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
-
SQL Server: `append_events` does not need the `@inserted` table variable対応中かも @nmummau が 8 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 20/100
Eventuous/eventuous#619 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
-
SQL Server: stream reads do one key lookup per event, and `IDX_EventsStream` duplicates `UQ_StreamIdAndStreamPosition`対応中かも @nmummau が 8 日前に担当しました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 18/100
Eventuous/eventuous#618 · コメント 1 件 ·
メンテナーはふだん 7 日以内に返信
Eventuous/eventuous の issue をすべて見る
似ている issue
-
area: client bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug mcp misleading small
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
Bug Platform: Android
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
getsentry/sentry-dotnet#5764 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
microsoft/SimpleL7Proxy#287 ·
メンテナーはふだん 1 日以内に返信