Standard representation for assertion expected and actual values
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 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 分钟
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ctrf-io/ctrf 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 76/100
-
难度 3/5 半天 新手友好度 32/100
-
难度 4/5 1-2 天 新手友好度 48/100
-
难度 5/5 一周以上 新手友好度 35/100
-
难度 5/5 一周以上 新手友好度 35/100
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 75/100
tesseract-ocr/tesseract#4653 ·
维护者通常 1 天内回复
-
Four problem loader browser tests fail on Windows可能已有人在做 @Patriciaath999 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
good first issue help wanted windows
难度 2/5 1-3 小时 新手友好度 80/100
-
HttpRequestTrait fatals on WordPress 7.2: $blocked_http_requests clashes with WP_UnitTestCase_Base未关闭
难度 2/5 1-3 小时 新手友好度 72/100
-
test_pgbouncer deploys the server under test from Charmhub instead of the local build (track/1.31)未关闭bug
难度 2/5 1-3 小时 新手友好度 68/100
canonical/temporal-k8s-operator#195 · 1 条评论 ·
维护者通常 4 天内回复