Tests et qualité¶
Exécuter les tests¶
La configuration est portée par phpunit.xml.dist : le bootstrap de la suite est
tests/bootstrap.php, et APP_ENV est forcé à test pour l'exécution. Les variables
d'environnement de cet environnement viennent de .env.test, versionné dans le dépôt (voir
Configuration pour l'ordre de chargement des
fichiers .env*).
phpunit.xml.dist ne définit qu'une seule suite (Project Test Suite), qui couvre l'ensemble du
répertoire tests/.
Organisation des tests¶
À la date de rédaction de cette page, tests/ ne contient qu'un seul fichier :
tests/bootstrap.php, qui amorce l'environnement Symfony avant l'exécution de PHPUnit
(chargement de config/bootstrap.php s'il existe, sinon Dotenv::bootEnv() directement).
Aucune classe de test n'est présente dans le dépôt à ce stade — ni test unitaire, ni test
fonctionnel, ni test d'intégration. Il n'y a donc pas, pour l'instant, d'arborescence de
répertoires (tests/Unit, tests/Functional, etc.) à documenter : en créer une par anticipation
serait décrire une organisation qui n'existe pas. La checklist de
Contribuer recommande qu'une correction de bug
s'accompagne d'un test qui échoue avant le correctif ; c'est, à ce jour, la seule convention de
test formalisée pour ce projet.
Base de données de test¶
.env.test définit les variables lues par le kernel Symfony en environnement test
(KERNEL_CLASS, APP_SECRET propre aux tests, SYMFONY_DEPRECATIONS_HELPER, et des variables
liées à Panther pour d'éventuels tests navigateur). Il ne redéfinit pas DATABASE_URL : en
l'absence de surcharge, une exécution de tests qui toucherait la base de données utiliserait donc
la même connexion que l'environnement dev (voir Configuration), sauf
surcharge locale via .env.test.local. Comme tests/ ne contient aucun test à ce jour, ce point
n'a pas d'incidence pratique pour l'instant.
Analyse SonarQube¶
Outillage absent d'un clone frais
docker-compose.sonarqube.yml, sonar-project.properties et docker/sonarqube/Dockerfile
sont tous les trois listés dans .gitignore. Ils existent sur les postes qui les ont créés
localement, mais un clone frais du dépôt ne les contient pas : il faut les recréer avant de
pouvoir suivre les étapes ci-dessous.
sonar-project.properties configure l'analyse : clé de projet bcard-app, encodage UTF-8,
sources analysées limitées à src, templates et public/assets/new_design/js, et une liste
d'exclusions couvrant notamment vendor/, var/, les répertoires de téléversement publics et
docker/.
Démarrer SonarQube en local¶
docker-compose.sonarqube.yml ne démarre pas un serveur SonarQube lui-même : il construit et
lance un service scanner, à partir de docker/sonarqube/Dockerfile (une image contenant le
sonar-scanner CLI), qui se connecte à un serveur SonarQube déjà accessible via
SONAR_HOST_URL (http://host.docker.internal:9000 par défaut). Un serveur SonarQube doit donc
tourner séparément — par exemple l'image officielle sonarqube, lancée indépendamment de ce
projet — avant de pouvoir exécuter une analyse.
Lancer une analyse¶
Le service scanner attend la variable SONAR_TOKEN, un jeton d'authentification généré côté
serveur SonarQube, transmis au scanner via -Dsonar.token. Le répertoire du projet est monté
dans le conteneur (./:/usr/src/app) et analysé en place
(-Dsonar.projectBaseDir=/usr/src/app).
Vérifications avant merge request¶
La liste des vérifications à effectuer avant d'ouvrir une merge request (tests, cache, secrets, migrations, message de commit) est tenue à jour dans Contribuer ; elle n'est pas dupliquée ici.