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

Asserting on syntax paths in analysis tests

Abierto
#683 0 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
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Área
testing-qa, tooling

Línea de trabajo

Comienza con los casos de prueba de análisis y las formas de aserción #lang resyntax/test descritas en el issue. Compara el comportamiento existente de @assert con las opciones @within ... @inspect ... y revisa el issue #653 para conocer el formato de la ruta de sintaxis. Se considera terminado cuando las pruebas de análisis puedan afirmar referencias de rutas de sintaxis de una forma que gestione bloques de código repetidos y sea útil para los autores de pruebas.

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

Descripción

testing

Currently, analysis-test test cases can only make assertions about analyzer property values being basic literal datums like strings, numbers, and symbols. But it's very useful for analyzers to add cross-references between different syntax objects using syntax paths, and analysis tests should be able to make assertions about that. One way for this to work would be to support the string syntax path format mentioned in #653 as a literal datum in #lang resyntax/test.

Another might be to do something like the @within ... @inspect ... options, like an @assertReferences <codeblock> @within <codeblock> alternative to @assert <value>, which would assert that the tested property value is a syntax path referring to a part of the test program identified by <codeblock> @within <codeblock>. Like @within <codeblock> @inspect <codeblock>, the @within <codeblock> part should be optional and its purpose is to disambiguate when the expected code block occurs multiple times within the test program.

The latter approach seems better from a user perspective, because it's difficult to tell what a syntax path corresponds to in a given textual program. Syntax paths are much more useful when looking at raw S-expressions than arbitrary surface syntax code strings.

Lenguaje dominante
Racket
Estrellas
70
Forks
11
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

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 jackfirth/resyntax

Todos los issues de jackfirth/resyntax

Issues similares

Más issues de Testing & QA

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.