Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

discussion:make testing.md more concise and decision-oriented for contributors

Aperta
  • Qualcosa non va?
#3,965 6 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
javascript
Ambito
documentation, testing

Direzione di ricerca

Inizia leggendo testing.md e confrontando l’organizzazione documentata dei test lato client con il pattern test/ lato server descritto nell’issue. Conferma l’approccio preferito con i maintainers prima di modificare qualsiasi cosa; il risultato dovrebbe essere una guida concisa e orientata alle decisioni che spieghi chiaramente la posizione accettata dei test e i passaggi successivi per i contributors.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Area: Documentation Feature Request Needs Discussion
Increasing Access

While working across both the client and server codebases, I noticed that the repository currently follows two different test organization models, but only one of them is documented.

Client-side (documented): tests colocated adjacent to source files

Server-side (undocumented): tests grouped inside a dedicated test/ folder per module

Based on hands-on contribution experience, I strongly lean toward the server-style test-folder model as a more scalable and contributor-friendly approach, especially for larger directories.

Feature request details
Why this matters (practical impact)

In several client component directories, there are 20–25 files, where test and story files are mixed directly with production code. This has a few concrete downsides:

  • Contributors must repeatedly scan past test files to locate actual components
  • It becomes harder to visually distinguish production code vs test code
  • Directory navigation cost increases as the project grows
  • New contributors face higher cognitive load when exploring the codebase

By contrast, the server-side pattern:

module/
  controller.js
  service.js
  test/
    controller.test.js
    service.test.js

keeps production code immediately visible, while still maintaining strong test coverage.

This suggests the repository already has a proven, scalable testing model in use — just not consistently documented or discussed.

Documentation concern (testing.md)

Another related observation is that testing.md is currently very long (~550 lines) and highly procedural. While thorough, it can be overwhelming for contributors who just want to answer:

  • Where should I put my test?
  • What pattern should I follow in this part of the codebase?

This makes it harder to quickly internalize expectations, especially for first-time contributors.

Image

There may be an opportunity to:

  • Make the document more precise and decision-oriented
  • Clearly explain accepted test organization patterns
  • Reduce cognitive overhead without removing useful detail
Discussion points / questions

I’d love maintainer input on the following:

  1. Is the server-style test/ folder considered a preferred or more scalable pattern going forward?

  2. Would it make sense to explicitly support and document this model, at least for larger modules or new code?

  3. Should testing.md distinguish between:

    • Small components (adjacent tests acceptable)
    • Larger modules (grouped test folders recommended)?

  4. Is there interest in making testing.md more concise and guidance-focused, possibly with a short “Quick Start / Best Practices” section?
    Maintainers (@raclim ) wdyt?

Lingua principale
JavaScript
Stelle
1.7k
Fork
1.7k
Merge medio
3g 18h
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di processing/p5.js-web-editor

Tutte le issue di processing/p5.js-web-editor

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.