Le problème est mon test doit porter sur la fonction echouer_etape_3b() qui est typée never (elle appelle exit). Les autres tests ne traitent pas ce type de fonctions. Du coup, est-ce qu’il y a eu une réflexion sur les choix d’implémentation ?
Voici les deux directions qui me sont proposées :
Tester la fonction directement avec #[RunInSeparateProcess] pour isoler le exit dans un sous-processus
Tester plus haut : simuler un POST avec un login trop court et vérifier que la réponse HTTP contient le bon HTML
Dans tous les cas il est fort probable qu’on doive refondre assez profondément cet installeur pour SPIP 5…
Je n’ai pas de réponse précise à t’apporter mais on utilise déjà #[RunInSeparateProcess] à différents endroits (à cause des globales notamment parfois).
Après, a priori, au plus près tu testes mieux c’est (donc dans la fonction a priori — dont je n’ai aucune idée de quoi tu parles mais je n’ai pas le code sous les yeux)
Je sais pas si c’est vraiment le plus pertinent de mettre des tests sur ces fonctions très legacy néanmoins, surtout si tu sais corriger le problème par ailleurs.
On souhaite qu’il n’y ait plus de tests « d’intégration » dans SPIP5 tels qu’ils sont présents historiquement.
Le très bas niveau de coverage de spip/ecrire via les tests unitaires, nous inclinent à poursuivre l’effort de découpage du contenu de ce dépôt, de recoder l’essentiel en POO et à produire des T.U. isolés, en enrichissant, si possible spip-league/sdk avec des Mocks réutilisables pour les plugins.
On s’est noté en TODO la refacto des étapes d’install, très certainement sous forme de composant indépendant.
Je ne vois pas comment on peut se passer de tests d’intégration (désolé, je ne suis pas expert). Et quand j’ai demandé à CC si le bug pouvait être testé avec uniquement des tests unitaires, j’ai du mal à interpréter sa réponse.
Je la livre au cas où ça ait un sens pour vous :
Non, et voici pourquoi:
Installation::setOptions() appelle des fonctions SPIP:
$options['titre'] = _T('info_installation_systeme_publication'); // SPIP
$options['css_files'][] = find_in_theme('installation.css'); // SPIP
Et Admin::setOptions() aussi:
array_unshift($options['css_files'], find_in_theme('minipres.css')); // SPIP
Le constructeur de AbstractPage appelle lui aussi include_fichiers_fonctions(), include_spip(), etc.
Les classes minipage sont complètement couplées à l'écosystème de fonctions globales de SPIP -
aucune ne peut être instanciée sans SPIP chargé.
Ce qui serait testable en unitaire si les fonctions étaient mockables : la logique de fermeCorps() -
"si footer est '' alors pas de <footer>" - mais les fonctions globales PHP (_T(), url_de_base(), etc.)
dans un namespace différent du code ne peuvent pas être shadowées sans extension (runkit7, uopz).
C’est peut-être cette histoire de namespace différent que tu évoques avec la POO, c’est cela ?
J’ai mis à jour les tests pour ce PR (le cas normal d’installation réussie n’était pas vérifié) et fait une correction mineure sur un commentaire (hors scope) pour que les tests CI passent tous.
Comment est-ce que ça se passe ensuite ? Est-ce que vous avez accès au PR pour commenter et valider ou non ?
PS. : Ma contribution ici est faible. J’ai essentiellement dirigé mon outils de codage, sans maitriser les risques de débordement que peuvent introduire mes modifs. J’essaie de limiter les risques avec des tests. Il y a peut-être des approches plus propres que le code proposé (les skills que j’ai mis en place restent imparfaits et mes récents devs ont surtout pour motivation de les consolider). Je vois beaucoup de projets qui refusent les PR générés par des IA, je comprendrai tout à fait si vous prenez la même option.
