Hop,
Perso je pense qu’il faut faire comme le disait @maieul c’est à dire tester les fonctions de base et y aller sans complexe si on sait qu’on est prêt à assurer le support quand les users tomberont sur des bugs qu’on n’avait pas repéré. Mais, je pense aussi qu’on peut se prémunir de pas mal de bugs si on fait ces tests en activant l’affichage des erreurs & warnings de PHP cf Les aides au débuggage de squelettes - SPIP.
Et surtout, amha il faut brancher les plugins afin de se concentrer sur leur maintenance pour les branches SPIP supportées, 4.1 & 4.2 à ce jour donc PHP 7.4 mini. À partir de là, on peut s’appuyer sur les outils qu’on utilise pour le core afin de se simplifier le travail (rector, phpstan et phpcbf) et être certain que le plugin ne posera pas de problème avec la version de PHP utilisée. J’ai un petit article de récap en cours de rédaction à ce sujet, je vous ferai signe quand il sera publié. Et comme le disait @eric_tonton si on a le bon goût d’utiliser un IDE, celui-ci permet de repérer facilement les erreurs grossières dans le code.
On a déjà lancé le chantier de « branchage » sur quelques plugins, et comme on peut le voir pour crayons qui était compatible de SPIP 3.1 à 4.1 (donc deux versions non maintenues de SPIP !) ça permet de faire un sacré ménage dans le code https://git.spip.net/spip-contrib-extensions/crayons/pulls/15/files. Cela permet d’assurer un suivi et des montées de versions bien moins douloureuses et chronophage pour les personnes en charge de la maintenance du plugin, et donc la pérennité du plugin.
Après, il reste bien sûr à tester la compatibilité avec les APIs de SPIP, ses boucles et ses critères, les libs JS, mais de ce côté là les différents fichiers CHANGELOG permettent maintenant de repérer la plupart des choses qui cassent d’un version à une autre, et ça c’est vraiment bien (même si ça demande un effort supplémentaire à l’équipe du core pour les renseigner convenablement).
