Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Standard representation for assertion expected and actual values

Abierto
  • ¿Algo no está bien?
#67 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
json
Área
testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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:

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

  1. Does CTRF want first-class structured assertion data, such as optional expected and actual fields on both the Test object and Attempt History Entry object?
  2. If so, should values be strings (matching many framework protocols), arbitrary JSON values, or a richer assertion/diff object?
  3. How should multiple assertion failures from one test be represented: only the primary failure, or an ordered array of assertion failures?
  4. 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.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
99
Forks
4
Merge medio
1 h 21 min
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ctrf-io/ctrf

Todos los issues de ctrf-io/ctrf

Issues similares

Más issues de Testing & QA

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.