Standard representation for assertion expected and actual values
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 30/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- json
- 領域
- testing-qa
調査の方向性
Start with the linked JsonTestWriter.cs locations for normal and retry attempts, then review CTRF’s current specification and schema alongside issue #53. Compare how expected and actual values are represented by Microsoft.Testing.Platform and identify the schema decisions the issue asks for. Done means a maintainer-approved direction for structured assertion data or documented guidance for using extra.
索引モデルが issue の本文から書いたものです。
説明
Producer context
Microsoft.Testing.Platform has a first-class assertion-failure payload with separate Expected and Actual strings (AssertionFailureProperty). Its terminal and protocol reporters preserve those values so consumers can render a useful diff.
The CTRF reporter currently cannot preserve that structure. It emits only the failure message and trace defined by CTRF:
- https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Extensions.CtrfReport/CtrfReportEngine.JsonTestWriter.cs#L58-L66
- retry attempts have the same limitation: https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Extensions.CtrfReport/CtrfReportEngine.JsonTestWriter.cs#L220-L228
We searched the current specification, schema, issues, discussions, and pull requests and found no standardized expected/actual assertion fields. Issue #53 also indicates a preference to promote broadly useful concepts to first-class CTRF fields rather than create incompatible extra conventions.
Questions
- Does CTRF want first-class structured assertion data, such as optional
expectedandactualfields on both the Test object and Attempt History Entry object? - If so, should values be strings (matching many framework protocols), arbitrary JSON values, or a richer assertion/diff object?
- How should multiple assertion failures from one test be represented: only the primary failure, or an ordered array of assertion failures?
- If this is intentionally outside the core schema, is the recommended mapping a producer-namespaced object under
extra, and should CTRF document a suggested semantic shape so producers remain interoperable?
Why this matters
Flattening expected/actual into message loses machine-readable comparison data and forces every CTRF consumer to parse framework-specific prose. Keeping it only in a producer-specific extra shape preserves the data but fragments interoperability. Guidance on the intended level would let MTP map the existing structured assertion payload correctly without prematurely prescribing a schema design.
- 主要言語
- 言語のデータがありません
- スター
- 99
- フォーク
- 4
- 平均マージ
- 1時間 21分
- マージ済み PR（30日）
- 1
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
ctrf-io/ctrf のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 76/100
-
難易度 3/5 半日 初心者へのやさしさ 32/100
-
難易度 4/5 1〜2日 初心者へのやさしさ 48/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
eval-drift
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
-
test: TestServeUntilStale races the server's close against the client's sendall (BrokenPipeError under load)対応中かも @evoludigit が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 89/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
-
[BUG] Container scenario crashes without expected_recovery_time, kube DNS example uses retry_waitオープンneeds-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
krkn-chaos/krkn#1627 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信