Testing and Code Checks

What each check protects, how to run the existing suites, and which gaps are not covered by CI.

Tests and analyzers answer different questions. Use the smallest check that reproduces the change while developing, then run the repository's broader suite before delivery.

Symfony `api` checks

The combined symfony/code-analyzer.sh script checks:

Check	What it protects
OpenAPI validation	Generated routes and schemas form a valid API document.
PHPMND	Suspicious unexplained numeric constants in business code.
PHP CS Fixer dry run	Formatting expected by the project.
PHP_CodeSniffer	Additional style rules from `phpcs.xml.dist`.
Rector dry run	Code that differs from configured automated refactoring rules.
PHPStan level 8	Type and nullability mistakes across shared, admin, mobile, and tests.
PHPUnit	Shared, admin-controller, and mobile tests.

From a shell that can run the checked-in Bash script:

cd api/symfony
./code-analyzer.sh

The script expects the Docker container named api to be running. Most checks are read-only, but it temporarily creates spec.json and removes it after OpenAPI validation.

Focused PHPUnit

From C:\Users\user\work\agapi\api:

docker exec api ./vendor/bin/phpunit --testdox
docker exec api ./vendor/bin/phpunit --testdox --filter BookingControllerTest

Use a focused test while changing one rule, then run the full suite. A booking or payment fix should cover the failure/edge path that made the behavior unsafe, not only the happy response.

Individual read-only checks

docker exec api ./vendor/bin/phpstan analyze
docker exec api sh -c "PHP_CS_FIXER_IGNORE_ENV=1 ./vendor/bin/php-cs-fixer fix --dry-run --diff"
docker exec api ./vendor/bin/phpcs --standard=./phpcs.xml.dist -p -s -n --ignore-annotations
docker exec api ./vendor/bin/rector process --dry-run --clear-cache

Commands without --dry-run, such as PHP CS Fixer apply or Rector apply, change files. Run them only when that rewrite is intended and review the diff.

`agapi-member-booking` tests

The repository contains two older test projects:

Suite	Location	What it covers
API tests	`testing/api`	Mocha/Chai checks against configured HTTP behavior.
End-to-end tests	`testing/e2e`	Protractor/Jasmine journeys across admin, booking, check-in/out, requests, service, and related APIs.

They use old Node/test dependencies and require their own configured environment. Do not run them against shared or production data.

From the suite directory, the declared entry points are:

npm test

For end-to-end work, read testing/e2e/config and its Docker setup first. The tests can create and change operational records, so use an isolated test database.

Documentation checks

From C:\Users\user\work\agapi\docs:

pnpm exec tsc --noEmit --incremental false
pnpm build

Also open changed pages in the browser. A successful MDX build does not prove that a wide Mermaid diagram, table, link, or mobile layout is usable.

What current CI does not prove

The checked-in GitLab pipelines run secret/quality scanning, image build, container scanning, and deployment jobs. They do not visibly invoke code-analyzer.sh, PHPUnit, or the old testing suites.

Therefore, a green pipeline is not proof that feature tests passed. Record the focused and full local test commands separately in the change handoff.

Symfony api checks