dotnet-coverage collect --server-mode leaks coverage across tests when using snapshot -r
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 52/100
調査の方向性
ドキュメント化された server-mode のフローから始め、Test A と Test B について、一覧にある collect、connect、snapshot -r、merge、shutdown コマンドを使って問題を再現します。merge または mapper による処理の前に raw snapshot 出力を調べます。各 snapshot に直前の reset 以降に収集された coverage だけが含まれ、.coverage ファイルが破損していなければ完了です。
索引モデルが issue の本文から書いたものです。
説明
We are observing that in a long-lived server-mode session, calling snapshot -r does not appear to fully clear prior coverage state. Coverage from an earlier test is still present in the next snapshot, and the raw .coverage file is already corrupted before any mapper/parsing logic executes. This is causing to collect the per test coverage when the test cases needs to run in sequence.
Steps:
- Start a shared coverage session:
cmd : dotnet-coverage collect --server-mode --background --session-id
2. Connect and run Test A in that same session:
cmd : dotnet-coverage connect dotnet test
3. Snapshot Test A with reset:
cmd : dotnet-coverage snapshot -r -o -t
dotnet-coverage merge -o -f xml
4. Connect and run Test B in the same session:
cmd : dotnet-coverage connect dotnet test
5. Snapshot Test B with reset:
cmd : dotnet-coverage snapshot -r -o -t
dotnet-coverage merge -o -f xml
6. Observe coverage contamination between Test A and Test B.
7. Shut down the server at the end
cmd: dotnet-coverage shutdown -t
Expected:
Each snapshot should produce coverage for only the test that executed since the previous reset. The -r option should clear the previous coverage state after creating the snapshot.
Actual:
The second snapshot still contains coverage from the earlier test or from a previous unrelated run. The raw .coverage output is already incorrect before mapper logic runs, which indicates the issue is in the coverage engine/server-mode reset behavior and not in downstream parsing.
Impact:
Incorrect coverage attribution, false pass/fail evidence, broken file-to-test mapping.
Note:
This issue is specific to dotnet-coverage collect --server-mode with repeated snapshot -r calls in the same process/session. It is not the same as MTP JSON-RPC server mode (--server / --server jsonrpc), which is a separate feature for IDE/tooling integration. The bug is therefore in the coverage collector/server-mode flow, not in the MTP test runner or mapper logic.
Relevant docs:
https://learn.microsoft.com/en-us/dotnet/core/testing/microsoft-testing-platform-code-coverage
https://learn.microsoft.com/en-us/dotnet/core/testing/microsoft-testing-platform-server-mode
https://github.com/microsoft/codecoverage
- 主要言語
- C#
- スター
- 125
- フォーク
- 17
- 平均マージ
- 1時間 15分
- マージ済み PR（30日）
- 2
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/codecoverage のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
microsoft/codecoverage#252 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
microsoft/codecoverage#251 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
microsoft/codecoverage#249 · コメント 1 件 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
microsoft/codecoverage#220 · コメント 2 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 66/100
microsoft/codecoverage#218 ·
microsoft/codecoverage の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
elsa-workflows/elsa-core#8593 ·
メンテナーはふだん 1 日以内に返信
-
NEW ISSUE Requestor-TML Maintainers Type: Change/Feature Request
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
tModLoader/tModLoader#5476 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
521xueweihan/HelloGitHub#3845 · コメント 1 件 ·
-
possible bug
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
-
documentation task
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100