Meilleures pratiques pour le test de régression des sites Web WordPress?

21

Bonjour à tous

J'aimerais savoir ce que les autres fournisseurs de solutions complexes autres que les blogs avec des clients utilisant WordPress constituent une plate-forme qu'ils utilisent pour l'automatisation Test de régression ?

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

  

Par test de régression, on entend tout type de test logiciel visant à détecter les 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 testant à nouveau le programme. Les tests de régression ont pour but d’assurer qu’une modification, telle qu’une correction de bogue, n’a pas introduit de nouveaux bogues.

Pour en savoir plus sur Wikipédia, voici ce que je ressens actuellement dans un projet:

  

L'expérience a montré que, les logiciels étant corrigés, l'apparition de nouvelles erreurs et / ou la réapparition d'anciennes erreurs sont assez courantes. Parfois, la réémergence se produit parce qu'un correctif est perdu à cause de mauvaises pratiques de contrôle de révision (ou d'une simple erreur humaine dans le contrôle de révision). Souvent, une solution à un problème sera "fragile" en ce sens qu'elle résoudra le problème dans le cas le plus étroit où il a été observé pour la première fois, mais pas dans des cas plus généraux pouvant survenir au cours de la durée de vie du logiciel. Souvent, un correctif pour un problème dans un domaine provoque par inadvertance un bogue logiciel dans un autre domaine. Enfin, il arrive souvent que lors de la refonte de certaines fonctionnalités, certaines des erreurs commises lors de la mise en œuvre initiale de la fonctionnalité ont été commises lors de la refonte.

En raison de la nature globale des actions et des filtres, je constate que la complexité augmente à mesure que j'ajoute une fonctionnalité supplémentaire demandée par le client et qu'il devient difficile d'obtenir un plugin stable, en particulier s'il utilise beaucoup d'appels vers WP_Query . et met à jour la base de données beaucoup.

La solution dans mon esprit serait de mettre en place des tests de régression avec une série de "scénarios de test" pour constituer une "suite de tests". En principe, ce n'est pas ça difficile lorsque vous testez la sortie HTML des requêtes HTTP GET. Mais cela devient un peu plus compliqué lorsque vous devez tester des éléments lorsque vous vous connectez via la console d’administration et / ou que vous testez les interactions jQuery.

Je suis en train de le configurer comme un wiki de communauté dans l’espoir de pouvoir rassembler les meilleures pratiques ici, mais je suis vraiment impatient d’entendre les processus si d’autres professionnels de WordPress l’utilisent.

    
posée MikeSchinkel 02.12.2010 - 06:40

3 réponses

10

On pourrait penser à PHPUnit si la suite de tests de WP n’était pas aussi endommagé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 du point de vue fonctionnel avec des tests unitaires et autres. Le problème est que ces tests ne garantiront pas qu’ils saisiront de subtiles chances introduites par les mises à niveau de WP, sans parler du fait qu’ils continueront de fonctionner une fois qu’ils seront connectés à une installation personnalisée de WP.

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

  • Un changement subtil dans l'API WP affecte la fonctionnalité de votre plugin, par exemple. le crochet sur lequel vous êtes habitué à obtenir un identifiant de terme et il obtient maintenant un identifiant de taxonomie de terme. (Il est probable que vos termes de test aient le même identifiant pour les deux).

  • Un changement subtil dans l'API WP a pour conséquence que vous recevez un objet WP_Error au lieu de la valeur précédemment attendue de false comme mauvaise entrée.

  • Votre plugin est ajouté depuis le dossier mu-plugins, ce qui entraîne un flux de code légèrement différent.

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

  • Votre plugin a bien fonctionné jusqu'à ce que le commutateur 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 en tant qu'effet secondaire.

  • Un plugin (un?) manipule sciemment vos données d'entrée ou de sortie au point que tout semble cassé, même si vous n'êtes pas en faute.

Je pourrais élargir la liste encore et encore, mais ce sont les éléments clés qui ont cassé mes propres plugins. Les deux articles sont discutables avec des tests unitaires. Les deux suivants également, 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 test ne fonctionnera autour de l'implémentation buggy de switch_to_blog (). Et les deux derniers sont désespérément incontrôlables.

Oh, et… ne me lance même pas sur l'assaut des pièces jointes, des brouillons automatiques, des révisions, des éléments de menu et autres éléments non enregistrés dans la table des posts.

Bonne chance ...: -)

    
réponse donnée Denis 02.12.2010 - 12:51
7

Vous devriez strongment envisager Selenium .

Il vous permet d’enregistrer des actions (par exemple, saisir des données dans un formulaire, cliquer sur un lien) et d’effectuer ensuite des assertions. Il s'intègre également à PHPUnit. Je recommande vivement de regarder la démonstration de deux minutes.

    
réponse donnée Ethan Seifert 04.12.2010 - 01:37
1

Le sélénium est probablement utilisable, mais je pense qu’aujourd’hui, Codeception sera meilleur et plus facile à utiliser. Pour le test de régression visuel le plus simple, il dispose même de une extension qui prendra des captures d'écran et les comparer automatiquement pour vous.

Bien sûr, les tests WebDriver de Codeception peuvent aller plus loin et effectuer des tests de régression fonctionnels . Vous pouvez remplir et envoyer des formulaires, cliquer sur des boutons et des liens sur le site, exécuter un JS, etc. Vous pouvez utiliser un navigateur réel, tel que Firefox ou Chrome, dans vos tests ou effectuer des tests sans assistance avec PhantomJS . Cela signifie que vous pouvez même exécuter les tests WebDriver pour votre plugin dans le cadre de son processus de création de Travis CI . si vous voulez.

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

réponse donnée J.D. 01.09.2016 - 18:28

Lire d'autres questions sur les étiquettes