Standard representation for assertion expected and actual values
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 30/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- json
- Ambito
- testing-qa
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 99
- Fork
- 4
- Merge medio
- 1h 21m
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ctrf-io/ctrf
-
Also Mention UUID version 8Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 76/100
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 32/100
-
Difficoltà 4/5 1-2 giorni Idoneità per principianti 48/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
Tutte le issue di ctrf-io/ctrf
Issue simili
-
affected/v17 affected/v18 area/frontend type/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
umbraco/Umbraco-CMS#24186 ·
I maintainer di solito rispondono entro 2 giorni
-
[BUG] to(attrs, inplace=True, num_threads=...) on a nested tensordict raises and leaves the nested leaves at the rootForse già presa @peterdsharpe l’ha presa oggi. Apertabug triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
pytorch/tensordict#2498 ·
I maintainer di solito rispondono entro 1 giorno
-
area: logo difficulty: easy good first issue testing
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement from-review
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
khuisman/mcp-gee-sweet#1009 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
snapotter-hq/SnapOtter#2424 ·
I maintainer di solito rispondono entro 1 giorno