Asserting on syntax paths in analysis tests
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Ambito
- testing-qa, tooling
Direzione di ricerca
Inizia con i casi di test dell’analisi e le forme di asserzione #lang resyntax/test descritte nell’issue. Confronta il comportamento esistente di @assert con le opzioni @within ... @inspect ... e consulta l’issue #653 per il formato del percorso sintattico. Il lavoro è completo quando i test dell’analisi possono verificare riferimenti a percorsi sintattici in un modo che gestisca blocchi di codice ripetuti e sia utile agli autori dei test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Racket
- Stelle
- 70
- Fork
- 11
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri 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 jackfirth/resyntax
-
Grimoire docs need examples Apertadocumentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
documentation
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
testing
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
testing
Difficoltà 3/5 1-2 giorni Idoneità per principianti 75/100
-
testing
Difficoltà 4/5 3-5 giorni Idoneità per principianti 68/100
Tutte le issue di jackfirth/resyntax
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
jaegertracing/jaeger-ui#4506 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Apertabot:ai-assisted component:indexer QA-roadmap status:untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
midnightntwrk/midnight-indexer#1557 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
Luminous-Dynamics/mycelix#3069 ·
-
bug ci good first issue needs testing
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
agent/quality hive/hosted-available-lke648397-260827-5n31 quality testing
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100