a-b-street / a-b-street/osm2streets
View test state in Street Explorer
- Langage dominant
- Jupyter Notebook
- Étoiles
- 156
- Forks
- 14
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
When working on any code covered by the tests, you'll have a rapidly changing test source directory. Sometimes `.orig` files will show up that should be compared to new output.
It would be easy for the test browser to interact with an HTTP API to list and load the tests on the fly. A simple poll could detect .orig files, and offer to view the diff for those tests. (We could later progressively enhance to use a websocket to talk to a test runner that's watching the files.)
*Note that we are moving away from `yew` in rust, and towards native JS.*
## Possibilities
`trunk` currently works as a perfectly cromulent web server with zero additional deps on the user.
`trunk` has a [proxy](https://trunkrs.dev/configuration/#proxy) setting that would let us easily pass a route through to whatever server we set up.
Serving files and directory indexes would get us 80% of the way there.
If we could write custom request handlers in rust, then we could do whatever fancyness we would need. We could even accept `.osm` (or a region to fetch) and create and run a new test.
Triggering tests that are run by the server would be cool, because the server can be set up to test in any way that we want, without needing to support the browser. E.g. we could generate a MapMachine rendering as part of the test or test any downstream users of osm2streets.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
L’issue décrit l’ajout d’un visualiseur de l’état des tests à Street Explorer, probablement dans l’interface web du projet. Commencez par examiner le code frontend existant de Street Explorer et son processus de build avec `trunk`. Cherchez comment les tests sont actuellement structurés et où les fichiers `.orig` sont générés. L’objectif est de créer une HTTP API (éventuellement en Rust) pour lister les tests et les diffs, et de l’intégrer au frontend. « Done » signifie que le navigateur peut afficher les fichiers de test et les diffs à la volée.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- javascript, rust
- Domaine
- frontend, testing, tooling
- Type d'issue
- Fonctionnalité
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100