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

Move the API test suite off Behat to PHPUnit

Aperta
  • Qualcosa non va?
#504 22 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
php, symfony
Ambito
testing

Direzione di ricerca

Start by reading CLAUDE.md and the testing configuration, then inventory the 69 feature files, 12 contexts, and their step definitions. The first step is to agree on the PHPUnit setup and porting guide with Daniel, then pilot the health and purge endpoint features with coverage, mutation, and behavior equivalence checks. Done means all scenarios are ported or deliberately dropped with reasons, Behat and its dependencies are removed, and the Symfony 8 functional suite runs.

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

Descrizione

Why

  • Symfony 8 is untested. behat/behat 3 and friends-of-behat/mink-extension 2 cap six Symfony components at ^7.0, so every Behat leg runs the test app on Symfony 7.4's framework, the ones named 8.1 included. The bundle claims Symfony 8 support that its API tests never exercise.
  • It depends on a fork. behatch/contexts is abandoned upstream; we depend on a fork. That fork pins justinrainbow/json-schema ^5, which is why Infection can't be a Composer dependency, and it needs the no-api repository workaround. Behat 4 waits on mink-extension 3 and the fork.
  • Mutation testing is blind to it. Infection scores only PHPUnit, so code reached only by Behat gets no mutation scrutiny, and every PR adds unit tests for the gate alone.
  • It runs without debug. The Behat app runs debug: false. The alpha.29 stopwatch 500 (#501) was invisible to it; the template's PHPUnit suite caught it.
  • API Platform left it. API Platform, the reason we adopted Behat, moved its own suite to PHPUnit's ApiTestCase.

Scale: 69 feature files, about 1078 scenarios, 12 contexts, about 9,850 lines of context code.

Goals

  • Every Behat scenario is ported to PHPUnit, or deliberately dropped with a reason. Behat, Mink and behatch are removed.
  • The tests read as well as the scenarios did: the test method name carries the behaviour (CLAUDE.md already says the reason belongs in the test name), with a small helper vocabulary.
  • A clear structure: unit tests stay small and isolated; functional tests describe behaviour through HTTP and console, in terms we can state and check.
  • Every ported area proves it catches what the old scenarios caught (see Equivalence).
  • At the end, two lists:
    • scenarios whose intent or result we're unsure of;
    • behaviour we should be testing and aren't.

Phase 1: choose and set up the replacement (with Daniel, before any porting)

Decide and write down, in CLAUDE.md and a porting guide:

  1. Framework: API Platform's ApiTestCase (its HTTP client, JSON and JSON-schema assertions) for API behaviour, and KernelTestCase with CommandTester for console commands.
  2. Kernels in PHPUnit. CLAUDE.md forbids booting a kernel in PHPUnit today: a debug boot registers Symfony's ErrorHandler, PHPUnit reports Risky, and Infection's initial run fails. Choose:
    • a separate functional suite that Infection doesn't run; or
    • solve it (e.g. debug: false for most tests, plus a debug-kernel suite for stopwatch and profiler behaviour). Prove the choice in the pilot.
  3. Structure and naming: e.g. tests/Unit/<Area> and tests/Functional/<Area> mirroring the feature areas, one test class per feature, and test_<behaviour> names.
  4. Helpers: replace the contexts with traits or fixtures: login as admin or user, Doctrine fixtures, profiler, purged tags, Mercure messages, cookies, console runs, the static test doubles. List each step definition and its replacement.
  5. Running: keep per-process isolation for parallel runs, as BEHAT_SHARD does now (AppKernel::shardSuffix()), plus coverage and Codecov uploads, and Infection's view of the new tests.
  6. Pilot: port two small features end to end, e.g. health.feature and the purge endpoints, with the equivalence check below. Daniel reviews the result as the template every later port follows.

Phase 2: port as a team

Once Phase 1 is agreed:

  • Work units: one feature file each, grouped into areas with a lead per area (main split by topic, user, fixtures, uploads, publishable and the rest), under one coordinator.
  • The coordinator keeps a tracker, assigns areas, merges in order, and resolves shared-helper changes.
  • Each port is one PR that:
    • adds the PHPUnit tests and deletes the scenarios it replaces;
    • passes the equivalence check;
    • lists anything the porter was unsure of.
  • Leads review their area's PRs against the porting guide before the coordinator merges. Daniel approves the guide and samples PRs, and doesn't need to review every one.

Equivalence: the new tests catch what the old ones caught

For each ported feature:

  1. Coverage. Record the old scenarios' line coverage (per-feature clover from CoverageContext) and require the new tests to cover at least those lines of src/. Any shortfall is listed and explained.
  2. Mutation. Run Infection with the new tests over the lines the old feature covered. Surviving mutants are fixed or listed. This is the gate Behat never had.
  3. Behaviour. Every assertion the scenarios made has a counterpart; the PR maps scenarios to tests.

Phase 3: finish

  • Remove Behat, Mink, the behatch fork, the no-api repository and bin/behat-parallel; move CI to PHPUnit suites; update CLAUDE.md's testing section.
  • Lift the Symfony 7.4 test pin and run the functional suite on Symfony 8.
  • Publish the two lists (unsure results; missing behaviour) as follow-up issues.
Lingua principale
PHP
Stelle
32
Fork
8
Merge medio
1h 1m
PR unite (30g)
159

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 components-web-app/api-components-bundle

Tutte le issue di components-web-app/api-components-bundle

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.