Après quelques tests j’ai mis au point une méthode qui permet de faire des tests unitaires et des tests d’intégration. Pour les premier, c’est du phpunit standard. Pour les second cela utilise spip/dev et une installation de spip dans vendor/spip/spip à l’aide de spip-cli + sqlite.
Est-ce la bonne manière de procéder ?
C’est un plugin tout simple, dont le but est surtout de pouvoir tester ecs, rector et l’ajout de tests divers sur les formulaires, autorisations, etc.
L’objectif est d’en faire une base pour une généralisation sous forme de skills de tests automatiques.
Merci, ça à l’air vraiment sympa. Je me demandais justement l’autre jour comment automatiser certains tests, pour arriver à la conclusion que ça faisait plus de boulot que je n’avais de temps dispo… Merci de le partager!
Hello @epilibre et autres : il me semble que ce point « comment ajouter des tests dans un plugin » devrait absolument se retrouver sur une ou plusieurs pages de la documentation officielle orientée « dev » sur programmer.spip.net.
Est-ce qu’il est donc possible de reformuler/compléter ce que tu aurais déjà rédigé, afin de proposer un article sur ce site, à faire relire et publier ensuite ?
C’est une bonne pratique qui semble de plus en plus important au fil du temps qu’on formalise et normalise les contributions, et ça ne devrait donc pas juste être un « conseil » : mais bien UNE manière de faire précise à documenter officiellement, afin que tout le monde s’y mette (à commencer par moi).
Faire des formations visios comme la proposé gentillement @maieul, c’est très bien mais pour moi ça vient « en plus », pour accompagner, aider encore plus celleux qui n’y arrivent pas (et qui arrivent à être dispos sur les créneaux). Mais il me semble vraiment indispensable qu’il y ait une documentation écrite officielle validée par la communauté, sur un site de la galaxie (donc Programmer car pour les devs).
Suivant la grosseur, possiblement ça serait pas juste un article mais une rubrique avec plusieurs courts articles focalisés (comme tout le reste de Programmer) :
comment installer l’infrastructure de test pour le noyau et/ou un plugin précis
comment lancer les tests déjà existants (afin de voir tout de suite si une modif du code provoque des changements)
comment écrire des nouveaux tests unitaires, avec plein de cas possibles (fonctions autonomes, ou nécessitant des données, etc)
si jamais on sait faire : comment écrire des tests fonctionnels (mais ça c’est vraiment l’étape loin après, d’abord prio à une doc officielle des tests unitaires)
Je confirme que le sujet des tests unitaires m’intéresse bien, mais que je ne pige pas ta documentation et comment l’utiliser, ni même ce que fait ton plugin.
Une petit complément qui aiderait bien, c’est la description de la situation de départ : ce que l’utilisation présuppose, ce qu’il faut avoir déjà en place, avant.
Ça poserait le cadre et aiderait a interpréter le contenu ensuite.
Quand même il faut préciser que SPIP 4.4 n’est pas vraiment prévu pour avoir des test d’intégration des plugins propres : c’est aussi un chantier qu’on a commencé en SPIP 5 et dont les mécaniques ont bien évoluées et continueront d’évoluer avant sa sortie.
Donc attention quand même avec ces propositions magiques d’IA en 4.4 qui proposent de faire des tests « avec l’existant » sans le remettre en question et en tordant tout pour que ça marchotte.
Je vais me pencher sur l’écriture d’une documentation en analysant ce qui se met en place pour SPIP5. Après tout, c’est utile de pouvoir préparer les plugins pour cette étape en amont
Pour l’IA je précise que je l’ai utilisé initialement pour comprendre comment ça marche actuellement, afin d’inclure les pratiques détectées dans la documentation des outils d’aide au codage pour les non spécialisés comme moi.
Le socle technique actuel de SPIP4.4 me semble assez solide pour des tests unitaires / fonctionnels voire e2e - Si ça ne l’est pas il faut documenter (et l’IA peut servir à cela)
J’ai poussé un peu plus loin les tests sur le projet des skills SPIP : un répertoire tests/ contient tout un tas de tests unitaires et tests d’intégration sur les plugins, les formulaires, les squelettes, le multilinguisme…
Certains tests sont volontairement en échec, c’est pour vérifier que Claude Code peut corriger en utilisant les skills et tout passer au vert.
Je vous invite à cloner le dépot, installer les dépendances pour tester les différents tests et ajouter les votres. C’est aussi simple qu’un simple composer install.
Vu que composer doit automatiquement installer une instance de test de SPIP, la version minimale de PHP est celle du composer de SPIP, à savoir 8.2.
ps.: pas de panique si ça mélange anglais et français, c’est assez fréquent car j’échange souvent en anglais avec CC pour économiser 30% de tokens et produire des skills en anglais (et ça se retrouve parfois dans les tests)
"expected_output": "Utilisation de #ENV**{erreurs}|table_valeur{titre} (double étoile) pour lire l'erreur, et du conditionnel SPIP [ (#ENV**{erreurs}|table_valeur{titre}|oui)erreur] pour la classe.",
Bah non… c’est essentiellement faux le expected que tu lui indiques. Je ne sais pas où tu prends cela ? En copiant des plugins (ou des docs ?) pas à jour ?
"expected_output": "spip_log() écrit dans des fichiers texte rotatifs dans tmp/log/ (usage développeur). journal() écrit en base de données, visible à ?exec=journal (usage audit administrateur).",
Tu as regardé ce que fait journal() dans SPIP par défaut (et nul par ailleurs d’ailleurs) ?
Pour le reste je n’ai fait que survolé, c’est certainement intéressant pour l’état actuel de SPIP 4, même si je préfèrerais que cette énergie soit utilisée pour l’améliorer, ou améliorer sa doc, pas pour le documenter pour 1 agent IA spécifique !
Je vois bien qu’il y a essentiellement un bon travail assez exhaustif dessus, mais qu’il n’est absolument pas relu convenablement : plein d’erreurs pour un « guide », ce qui est tout de même ennuyant, et des conventions un peu forcées j’ai lu aussi qui ne le sont pas en pratique…
La source c’est prive/formulaires/instituer_objet.html
Effectivement une seule étoile dans squelettes-dist/formulaires/ecrire_auteur.html donc je ne sais pas s’il y a une règle à respecter ou pas. Le « 1 étoile » est normal car c’est un tableau. Je vais creuser pour comprendre pourquoi instituer_object.html a 2 étoiles et supprimer la règle des skills sur la construction des formulaires standards (qui contient également des règles farfelues sur les classes des inputs, je pense les garder pour que ce soit des modèles de formulaires qui s’insèrent dans l’espace privé)
: la PR date de… 2021, a été co-améliorée par plusieurs personnes, et c’était bien ce code au départ.