Blog // Exirel.me

Je développe donc j'écris des tests unitaires.

Par Florian Strzelecki - 02:07 - 18.05.2011

Tags : J'aime, Programmation, Bonne pratique, Développement, Unit Testing, Technique

Suite à mon article sur PHPUnit, il m'a été posé la question, fort simple dans sa forme, de "Mais pourquoi faire des tests ?".

Après tout, cette question, je me la suis aussi posé avant de faire des tests, ainsi qu'à mon premier apprentissage, et encore aujourd'hui quand j'écris tel ou tel morceau de code, je me demande à quoi servent les tests que je vais écrire, ou que j'ai déjà écrit.

Je vais essayer de faire rapide, car expliquer "pourquoi faut-il faire des tests" n'est pas mon but premier : tout un tas de gens ont écrit tout un tas de choses sur le pourquoi comment, avec études théoriques et pratiques. Non, moi, je vais me contenter de vous exposer, de manière très subjective, pourquoi je fais des tests unitaires.

Tester mon implémentation

J'écris la plupart de mes tests pendant le développement, et jusqu'à présent, jamais avant d'écrire mes classes et mes fonctions. Je préfère d'abords écrire une classe, renseigner les méthodes principales, puis écrire les tests pour cette classe. Je passe ensuite à une autre classe, à d'autres tests, et ainsi de suite.

Du coup, écrire les tests unitaires d'une classe avant de passer à un autre morceau de mon code me permet d'identifier tout de suite quels sont les problèmes dudit code, avant même de l'avoir vraiment inclus au reste de l'application.

Résultat : des classes indépendantes les unes des autres, plus facile à utiliser, plus simple et une implémentation plus élégante, avec une orientation KISS.

Vérifier mon travail

Une fois que j'ai développer mon code, et que je suis fier de moi, je dois me rappeler d'une chose : l'orgueil est une mauvaise chose, et je ne dois pas oublier que je peux m'être trompé, même par simple inattention.

Alors les tests unitaires, en vérifiant que je teste bien tous les comportements voulus, me permettent simplement de vérifier, avec une facilité déconcertante et un automatisme rassurant, que ce que j'ai écrit fait bien ce pour quoi il a été écrit.

Résultat : un code sur lequel je puisse me reposer avec confiance, sur lequel je sais que je ne vais pas avoir besoin de revenir à cause d'erreurs humaines cachées.

Repérer les régressions et les erreurs d'optimisations

Une fois que le code est écrit, il m'est parfois nécessaire de revenir dessus, que ce soit pour l'optimiser ou lui ajouter de nouvelles fonctionnalités. Mais, précisément, dans ces cas là, une optimisation peut sembler bonne, mais avoir des effets de bords problématiques.

Ainsi, en relançant les tests unitaires, je peux vérifier que ce à quoi j'ai touché n'impacte en rien le bon fonctionnement de l'ensemble, et surtout ce à quoi je n'ai pas touché.

Résultat : Un code qui évolue sans effet de bord négatif et/ou inconnu.

Responsabilité et gain de temps

Comme le dit un ami "T'as le droit de tout péter, mais t'es obligé d'être au courant." - phrase pleine de bon sens et d'une saine vision de son travail.

Les erreurs existent, j'en fais, j'en ai fait (beaucoup), et je vais en faire d'autres, et même si j'espère ne jamais en faire, je sais que cela va arriver, alors autant que je sois au courant, et le plus vite possible.

Car ce sont pour moi là les deux enjeux des tests unitaires :

Et gagner du temps, tout en étant sûr de soi, c'est non seulement très agréable, mais c'est aussi une attitude plus professionnelle, une approche bien plus sérieuse, de ce que doit être mon métier au quotidien.

Sur ce, j'ai un projet à mettre en ligne... et il manque une partie de la documentation. C'est aussi quelque chose d'important, la documentation.