discussion: adding unit/integration tests for client . files

Abierto
#4,068 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

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
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
javascript, typescript
Área
testing

Línea de trabajo

Comienza revisando la cobertura propuesta para i18n.js, persistState.ts, reducers.ts, store.ts y theme.js, junto con los archivos cuyo omisión se ha propuesto. Determina qué archivos y comportamientos deben cubrirse, incluido si reducers.ts necesita una prueba smoke y si debería actualizarse testing.md; se considera terminado cuando se haya acordado el alcance y se hayan añadido las pruebas seleccionadas.

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

Descripción

Enhancement Needs Discussion

Proposed Tests

File Type What to Cover
i18n.js Unit languageKeyToLabel, languageKeyToDateLocale, currentDateLocale, language selection precedence (window.INITIAL_STATE vs detected fallback)
persistState.ts Unit Save/load/clear happy paths, invalid JSON, missing storage values, storage errors with console.warn
reducers.ts Smoke? Needs discussion — unsure if a smoke test is worth adding to verify combined state shape keys and init state, without re testing each child reducer deeply.
store.ts Unit showReduxDevTools() conditions, setupStore() behavior (persisted state precedence, clearState called, dev-tools enhancer toggling)
theme.js Unit remSize, prop success/error states, extend immutability/deep merge, key overrides in contrast theme

Files I'm skipping (browserHistory.js, constants.js, middleware.js) — don't seem to need tests, but open to feedback.


Discussion Questions

1. Which files actually need tests? Are the files in the table above the right ones to focus on, or are some not worth testing? Should reducers.ts get a smoke test?

2. Is this a priority right now? If not, which folders/files in the codebase would benefit most from test coverage first?

3. Should we update testing.md? Currently it's hard to know which files need tests. Would it make sense to add a checklist of all files that need coverage to testing.md in the contributor docs, and check them off as coverage improves? This would make it easier for contributors to pick up testing tasks without guessing.

Lenguaje dominante
JavaScript
Estrellas
1.7k
Forks
1.7k
Merge medio
8 d 22 h
PR fusionados (30 d)
14

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 processing/p5.js-web-editor

Todos los issues de processing/p5.js-web-editor

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.