Skip to content

Batterie de tests unitaire

Maïeul a demandé de fusionner gh-0536ee7e/315/unknown/refs/pull/315/head vers master

Cette PR envoie des tests unitaires pour une grosse partie de saisies. Pourquoi ?

  • par défi, pour mieux comprendre
  • pour pouvoir relier le code de saisies en même temps
  • pour la maintenabilité dans le temps
  • qui sait en vue d'une objectivisation puis composerisation de saisies (pas encore fait maintenant).

Préambule

  • Ne pas tenter de faire un diff avec gitea, vous allez morflez. Le mieux est de tester les tests unitaire
  • Cette PR inclut le code des PR suivantes : #305, #306, #314, #303 qui ont été constatés en préparent les tests unitaires.

Taux de couverture

La couverture des fonctions présentes dans inc est plutot pas mal. Certains cas sont problématiques et sont détaillés dans #308.

Un certain nombre de choses ne sont pas couvertes : tout ce qui est lié à cvt upload, qui devraient normalement plus être dans le code de saisies, mais déporté dans cvt upload via des pipelines

Variabilité des tests

Avoir un taux de couverture important ne suffit pas pour autant à s'assurer que les tests soient fiables. Il peut y avoir des combinaisons de paramètres importants : par exemple sur la syntaxe des afficher_si ou sur le moment où l'on doit vider les _POST. J'essaie donc dans la mesure du possible pour les fonctions les plus complexes de faire des tests complexes

Problématique lié à SPIP

Comme nous ne somme pas encore hyper modulaire ("pas composerisé"), je suis obligé de faire des pseudo fonctions de SPIP lorsqu'elles sont appelés dans le code de saisies. Voir le fichier tests/boostrap.php.

SI j'ai bien compris https://discuter.spip.net/t/bootstrap-framework-sdk/169501 le jour où SPIP sera composerisé, on pourra dit dans le composer.json qu'on nécessite des morceaux de SPIP, et ainsi mieux travailler les tests unitaires.

Concrètement

Le fichier README.md résume comment executer les tests.

  1. composer install (la tout première fois)
  2. vendor/bin/phpunit pour faire tout les tests
  3. XDEBUG_MODE=coverage vendor/bin/phpunit tests/ --coverage-html coverage --coverage-filter inc pour avoir un rapport de couverture sur le dossier inc, puis ouvrir coverage/index.html avec un navigateur.

Cela nous indique ce qu'il reste à faire, mais globalement on n'est nettement mieux qu'avant. Ca indique aussi un taux de CRAP, qui plus est elevé, plus montre que la fonction est difficile à maintenir.

Et maintenant

avis bienvenu, notamment des spécialistes @marcimat et @JamesRezo

Rapports de requête de fusion