Meilleures pratiques pour les tests de régression des sites Web WordPress?

Salut à tous,

J'aimerais savoir ce que les autres qui proposent aux clients des solutions complexes sans blog avec WordPress comme plate-forme utilisent-ils pour des tests de régression automatisés ?

Pour ceux qui ne connaissent pas le terme "test de régression", Wikipedia le définit comme:

Les tests de régression sont tout type de test logiciel qui cherche à découvrir des erreurs logicielles après que des modifications ont été apportées au programme (par exemple, des corrections de bogues ou de nouvelles fonctionnalités), en retestant le programme. Le but des tests de régression est de s'assurer qu'un changement, tel qu'un correctif de bogue, n'a pas introduit de nouveaux bogues.

Plus révélateur, Wikipedia dit ce qui est exactement ce que je vis sur un projet en ce moment:

L'expérience a montré que le logiciel étant fixe, l'émergence de nouveaux et / ou la réapparition d'anciens défauts est assez courante. Parfois, la réémergence se produit parce qu'un correctif est perdu en raison de mauvaises pratiques de contrôle des révisions (ou d'une simple erreur humaine dans le contrôle des révisions). Souvent, une solution à un problème sera "fragile" en ce qu'elle résout le problème dans le cas étroit où il a été observé pour la première fois, mais pas dans les cas plus généraux qui peuvent survenir pendant la durée de vie du logiciel. Souvent, une correction d'un problème dans une zone provoque par inadvertance un bogue logiciel dans une autre zone. Enfin, il arrive souvent que lorsqu'une fonctionnalité est repensée, certaines des mêmes erreurs qui ont été commises dans l'implémentation d'origine de la fonctionnalité aient été commises lors de la refonte.

Avec la nature globale des actions et des filtres, je constate que la complexité commence à augmenter à mesure que j'ajoute des fonctionnalités demandées par le client et qu'il devient difficile d'obtenir un plugin complexe stable, surtout s'il utilise beaucoup d'appels WP_Queryet met à jour beaucoup la base de données .

La solution dans mon esprit serait de mettre en place des tests de régression avec une série de "cas de test" pour comprendre une "suite de tests". Dans le concept, ce n'est pas si difficile lorsque vous testez la sortie HTML des requêtes HTTP GET. Mais cela devient un peu plus compliqué lorsque vous devez tester des choses lorsque vous êtes connecté via la console d'administration et / ou pour tester les interactions jQuery.

J'installe cela comme un wiki communautaire dans l'espoir que nous puissions rassembler les meilleures pratiques ici, mais je suis vraiment impatient d'entendre les processus si d'autres professionnels de WordPress utilisent.

PHPUnit me viendrait à l'esprit si la suite de tests WP n'était pas si cassée et si WP avait été conçu et écrit de manière à pouvoir être testé correctement. ;-)

Plus sérieusement, vous pouvez tester vos plugins tout ce que vous voulez de leur point de vue fonctionnel avec des tests unitaires et autres. Le problème est que ces tests ne garantiront pas qu'ils saisiront les chances subtiles introduites par les mises à niveau de WP, et encore moins qu'ils continueront à fonctionner une fois connectés à une installation WP personnalisée.

Parmi les choses colorées que j'ai vues se produire:

• Un changement subtil dans l'API WP affecte la fonctionnalité de votre plugin, par exemple le hook sur lequel vous êtes utilisé pour obtenir un identifiant de terme et il obtient maintenant un identifiant de taxonomie de terme. (Les chances sont bonnes que vos conditions de test aient le même identifiant pour les deux).

• Un changement subtil dans l'API WP se traduit par la réception d'un WP_Errorobjet au lieu de la valeur attendue précédemment falsecomme entrée incorrecte.

• Votre plugin est ajouté à partir du dossier mu-plugins, résultant en un flux de code subtilement différent.

• Votre plugin a bien fonctionné jusqu'à ce que memcached ou un autre magasin persistant soit activé.

• Votre plugin a bien fonctionné jusqu'à ce que le méprisé switch_to_blog () soit appelé.

• Un plugin change le hook sur lequel il réside lorsqu'il est appelé et l'interrompt sans le savoir comme effet secondaire.

• Un plugin (non?) Dérange sciemment avec vos données d'entrée ou de sortie au point où les choses semblent cassées même si vous n'êtes pas en faute.

Je pourrais étendre la liste indéfiniment, mais ce seraient les éléments clés qui ont cassé mes propres plugins. On peut soutenir que les deux éléments sont capturables avec des tests unitaires. Les deux suivants aussi, si vous êtes assez patient, mais je dirais que WP ne devrait pas changer la façon dont les choses fonctionnent lorsqu'elles se produisent. Aucune quantité de tests ne fonctionnera autour de l'implémentation boguée de switch_to_blog (). Et les deux derniers sont désespérément impossibles à tester.

Oh, et ... ne me lancez même pas sur l'assaut des pièces jointes, des brouillons automatiques, des révisions, des éléments de menu et ce qui finit par être stocké dans le tableau des messages.

Bonne chance... :-)

Vous devriez fortement considérer le sélénium .

Il vous permet d'enregistrer des actions (par exemple, entrer des données dans un formulaire, cliquer sur un lien) et ensuite vous pouvez effectuer des assertions. Il s'intègre également à PHPUnit. Je recommande fortement de vérifier la démo de deux minutes.

Le sélénium est probablement utilisable, mais je pense que dans les temps modernes, vous trouverez que Codeception est meilleur et plus facile à utiliser. Pour les tests de régression visuelle les plus simples , il a même une extension qui prendra des captures d'écran et les comparera automatiquement pour vous.

Bien entendu, les tests Codeception WebDriver peuvent aller plus loin et effectuer des tests de régression fonctionnelle . Vous pouvez remplir et soumettre des formulaires, cliquer sur des boutons et des liens sur le site, exécuter n'importe quel JS, etc. Vous pouvez utiliser un navigateur réel comme Firefox ou Chrome dans vos tests, ou vous pouvez effectuer des tests sans tête avec PhantomJS . Cela signifie que vous pouvez même exécuter les tests WebDriver pour votre plugin dans le cadre de son processus de génération sur Travis CI si vous le souhaitez.

Il existe même plusieurs bibliothèques spécifiques à WordPress pour vous aider à démarrer:

• Navigateur WP
• WP Codeception