Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Move the API test suite off Behat to PHPUnit

Abierto
  • ¿Algo no está bien?
#504 22 comentarios 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
php, symfony
Área
testing

Línea de trabajo

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.

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

Descripción

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.
Lenguaje dominante
PHP
Estrellas
32
Forks
8
Merge medio
1 h 1 min
PR fusionados (30 d)
159

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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

Todos los issues de components-web-app/api-components-bundle

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.