WCEU : Unit testing like a pirate

Plus de 4 minutes 🙂

Comme vous le savez peut être le WordCamp Europe s’est déroulé à Leiden du 5 au 7 octobre 2013. Durant ces 2 jours les conférences étaient rassemblées par thème. Celle-ci fait partie des conférences LEARN et le sujet est le test unitaire et elle est présentée par Ptah Dunbar.

Tout d’abord vous pouvez retrouver la conférence ici :

 

Mais que nous dit notre orateur ?

WordPress devient de plus en plus une plateforme pour créer des applications. La simplicité de l’administration permet de manier ses données de façon simple et surtout la pléthore des plugins d’étendre ses possibilités. Par exemple la plateforme live ninja qui utilise WP avec BuddyPress mais aussi nodejs. Doonc il est possible d’utiliser WordPress comme App.

Les plugins

Les plugins sont le coeur de WordPress, leur multiplicité permet de répondre aux différents besoin. La question est : Votre plugin peut-il être utilisé dans une grosse structure de Webapp ? On trouve beaucoup de plugins mais la qualité du code du repository de WordPress n’est pas bonne, alors qu’il faut se concentrer sur cette qualité. Déployer du nouveau code peut avoir des effets indésirables sur d’autres fonctionnalités, c’est ce que l’on appelle des effets de bord et il n’est pas facile de les détecter.

Actuellement :

• Tests fonctionnalités par fonctionnalités, une fonctionnalité finie, on valide puis on passe à la seconde
• C’est lent, il faut aller les faire soit même, cliquer, mettre les données, valider etc.
• On va surtout manquer des choses, on ne peut pas gérer tous les effets de bord

On a besoin de tester nos plugins, d’être sûr que tout fonctionne parfaitement, que nos clients soient contents.Il faut que se soit rapide et que la réponse soit claire, que tout soit réutilisable, donc que tout soit fiable.

Cependant PHP comparé aux autres langages n’est pas mature par rapport a ces demandes. On voit bien que Ruby, Python et autres sont bien adaptés pour gérer ce genre de choses.

La solution :

Le Unit testing bien sûr ! ( ou les tests unitaires ). On va donc écrire des test unitaires, ils   vont donner une réponse fiable sur ce qu’il s’est passé. Un test va tester une fonctionnalité et une seule fonctionnalité ! Ces test permettent de séparer le design du code, bien sûr ça ne teste pas le code javascript mais on est sûrs que le processus PHP s’est bien passé.

Les tests unitaires dans PHP :

Le framework de tests unitaires présenté est PHPunit et il y a le petit framework français atoum qui utilise les fonctionnalités de PHP 5.3 pour créer les tests.

Définition :

Un test unitaire : c’est un bout de code qui s’execute des certaines conditions, il y a ne valeur attendue et une valeur reçue, on vérifie donc que ce que l’on attend et ce que l’on reçoit est exactement pareil. Même si le résultat attendu est une erreur. Pour savoir si en passant un certain argument on retourne bien une WP_Error, on peut et on doit le tester.

Une suite de tests : Un ensemble de tests unitaire qui s’exécutent. Nous pouvons donc créer un ensemble de tests qui vont vérifier un ensemble de fonctionnalités comme par exemple un panier de site ecommerce etc.

Assertion : ce que l’on attend, on attend donc une valeur et la teste dans l’environnement réel pour savoir si tout s’est bien passé. Si on attend 56 mais que la fonction renvoie 10 alors le test échoue !

Un ensemble de fonctionnalités inhérentes au framework sont disponibles comme tester si on retourne bien true ou false que ce n’est pas NULL ou que le résultat contient une certaine valeur etc. (Voir la page 31 de la présentation )

La création d’un test unitaire :

Pour créer un test unitaire c’est simple, il ne faut que 3 choses : Une assertion ( ce que je veux ), une action ( ce que le code fait ) et un contexte d’exécution.

Exemple :

On veut tester une fonction d’addition, on va donc créer deux variables que l’on veut additionner par exemple 3 et 4 (contexte), on va exécuter notre fonction d’addition sur notre contexte (action) et vérifier que l’on va bien obtenir notre résultat, 7 (assertion). Si le test se passe bien alors il va signaler que tout s’est déroulé comme prévu.

Par contre il est plus difficile d’appliquer ça à WordPress car les plugins sont souvent mis dans des contextes ( hooks ). C’est donc dans la dernière partie(assertion) que la difficulté se trouve, il faut pouvoir prévoir ce que WordPress va nous retourner. Le plus simple est de découper son code de façon à ce qu’il soit testable de façon facile.

On peut donc tester son cache, vérifier des requêtes SQL etc. La meilleure façon d’écrire ses tests est de faire la liste des données requises et des conditions requises pour chaque fonctionnalité pour bien créer le bon contexte et créer l’interface utilisateur d’abord puis d’ajouter le code par dessus par la suite.

Je vous conseille de parcourir sa conférence pour avoir plus d’exemples.

L’auteur a créé un squelette de plugin qui va prendre en compte les tests unitaires :

https://github.com/ptahdunbar/wp-skeleton-plugin/

Conclusion :

Ce que nous pouvons retenir de cette conférence est qu’il est nécessaire et même indispensable de créer des tests unitaires, nous passons beaucoup de temps pour les écrire mais c’est la garantie d’éviter le maximum d’erreurs de syntaxe, de variable mal écrite etc.

Donc les tests unitaire bouffez-en et surtout habituez vous à en faire, qui sait ? Peut être un jour un de vos plugin deviendra payant et demandera d’avoir une qualité professionnelle et avoir un gros bug d’une version vous fera perdre des clients.