Unit-test the shipped frontend JavaScript with standard JS tooling (vitest)

Abierto
  • ¿Algo no está bien?
#7,611 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, javascript, node.js, python
Área
ci-cd, frontend, testing

Línea de trabajo

Read the pending work and related issues #7609 and #7610 first: the suite depends on which branch lands first and must be reconciled into one package.json, lockfile, and CI job. The issue names tests/js/, reflex_base/frontend/tests/, vitest.config.js, AGENTS.md, and unit_tests.yml as the relevant entry points. Done means Vitest with jsdom tests the shipped JavaScript, runs through a gated CI job, and is documented; the existing runtime scripts are a follow-up.

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

Descripción

roadmap

Problem

The JavaScript Reflex ships to every app (state.js, react-theme.js, upload.js, client state, the helpers and components under .templates/web/utils/) has no test suite of its own. Its behavior is only reachable through compiled output: Python unit tests can assert on generated source but not on runtime behavior, and Playwright integration tests are slow and indirect for things like provider teardown, SSR-versus-client branches, subscription bookkeeping, reconnect backoff or event-queue ordering. The two existing runtime checks (tests/units/compiler/state_js.test.mjs, tests/units/reflex_base/client_event_queue_runtime.mjs) are bespoke node scripts driven from pytest.

Proposal

Test the shipped JS with standard tooling: vitest + jsdom, with its own package.json and a committed package-lock.json, installed with npm ci and run as a js-unit-tests job in unit_tests.yml that blocks merges through unit-tests-gate.

  • Tests must not live inside the template tree that reflex init copies verbatim into a user's .web. While the runtime is still a template tree they live in tests/js/ and resolve $/... through a vitest alias; once the runtime ships as a package (#7609) they move into the package at reflex_base/frontend/tests/.
  • $/utils/state has to be stubbed today because the real module imports socket.io, react-router and the per-app generated utils/context.js. Decoupling the runtime from generated artifacts (part of #7609) makes state.js itself unit-testable.
  • Where JS and Python share a constant (for example the client-state registry key in constants/state.py, or the _download payload matcher in state.js versus the Var's _js_expr), a test asserts the two definitions agree so they cannot drift.
  • Document the suite, and when to reach for it versus Playwright, in AGENTS.md (npm --prefix tests/js ci && npm --prefix tests/js test).
  • New JS test files are formatted with biome under pre-commit; codespell skips committed lockfiles.

Pending work

  • #6936 (ClientStateVar refactor, #7610) introduces tests/js/: vitest.config.js, client_state.test.js, the js-unit-tests CI job and its gate wiring, and the AGENTS.md section.
  • The npm package branch for #7609 adds reflex_base/frontend/tests/ with state.test.js, runtime.test.js and helpers.test.js, and makes state.js importable in tests.
  • Land the suite with whichever of the two merges first, then reconcile the other so there is one package.json/lockfile and one CI job.
  • Follow-up: fold the existing .mjs runtime checks into the vitest suite so there is a single JS test entry point.

Related

  • #7609 installable npm package
  • #7610 ClientStateVar refactor (#6936)
Lenguaje dominante
Python
Estrellas
29k
Forks
1.8k
Merge medio
2 d 22 h
PR fusionados (30 d)
143

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 reflex-dev/reflex

Todos los issues de reflex-dev/reflex

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.