Sensibilisation au fameux “Clean Code” pour les tests automatisés. PARTIE 1

C’est quoi le “Clean Code”?

Traduit simplement, cela signifie “faire du code propre”. J’ai fait exprès de garder l’expression en anglais car je trouve que c’est stylé et que cela représente tout un concept ;-)

D’après Robert C. Martin, auteur du livre “Clean Code: A Handbook of Agile Software Craftsmanship”:

Le code est propre s’il peut être compris facilement — par tous les membres de l’équipe.

Un code propre peut être lu et amélioré par un développeur autre que son auteur initial.

Avec la compréhensibilité viennent la lisibilité, la modifiabilité, l’extensibilité et la maintenabilité.

Pourquoi faire du “clean code”?

Quand on commence à coder, on se focalise toujours sur l’écriture de code (comment faire une boucle, comment créer une fonction, comment cliquer sur tel bouton, etc…)

De ce fait, en tant que QA, on oublie souvent qu’il y a des facilitateurs (outils et des astuces) qui existent et qui nous aident beaucoup pour avoir un “code propre” mais qui sert aussi à éviter des erreurs d’inattentions.

Quelqu’un a dit : “Le temps est précieux pour qu’on puisse se permettre de le perdre”

En faisant du “Clean Code”, vous économiserez du temps :

• Sur la lecture et la re-lecture de code
• Sur les revues de code
• Sur le débogage des problèmes
• Sur la transmission de connaissance (oui, il faut penser aux autres qui vont reprendre votre travail)
• Sur la maintenance et la mise à jour du code
• Etc…

Et surtout, cela permet de faire du code de “QUALITE”!!!

Dans cette première partie, on va aborder les éléments du “clean code” qui concernent quelques principes et astuces.

Cela peut également vous épargner quelques soucis du type

“J’arrive dans 5min…”

Certains d’entre vous ont sûrement déjà vécu ces situations:

• Rater son train en pensant à un petit bug difficile à résoudre
• Dormir à 2H du matin pour chercher la solution, pour au final s’apercevoir que le coupable c’était une indentation manquante
• Dire à sa mère ou son partenaire le “j’arrive dans 5min…”, on connait tous la suite de l’histoire
• etc….

Comment appliquer le “Clean Code”?

Allons directement dans le vif du sujet.

Voici quelques exemples non exhaustifs sur son application.

Le système de nommage et le camelCase

Quand on écrit du code, on écrit des milliers de lignes de code dans des centaines de fichiers. Les noms sont donc très très importants.

Imaginez juste Deezer ou Spotify avec des noms de type: “album3 — artiste145 — piste54 — genre76”.

Si vous voyez ce que je veux dire, j’espère qu’à partir de maintenant, vous allez anticiper ces milliers de lignes de code et commencer à bien nommer vos fichiers, fonctions, classes, variables, etc…

Pour vous y aider, vous pouvez utiliser le principe du “camelCase” qui est une notation consistant à écrire un ensemble de mots en les liant sans espace ni ponctuation, et en mettant en capitale la première lettre de chaque mot.

On l’applique pour les noms des fichiers, des classes, des méthodes, des variables, etc…

Bien sûr, il ne suffit pas d’appliquer juste ce principe mais surtout utiliser des noms explicites et parlants. Sans ouvrir un fichier ou lire le contenu d’une fonction, on sait déjà à quoi ils vont servir.

NB: Il existe d’autres systèmes de nommage que le camelCase en fonction de ce que veut mettre en place l’entreprise. Par exemple, il y a l’under_scores.

La gestion des erreurs

Il faut s’attendre à gérer des erreurs ne provenant pas seulement du produit, mais du framework d’automatisation ou même de notre code de tests automatisés.

OUI, même en tant que QA (garant de la qualité), on génère aussi des bugs dans nos codes.

Le fait de tracer l’enchainement du code permet d’identifier plus facilement la racine d’un problème.

Prenons l’exemple d’une fonction de login. Il est recommandé de bien afficher (Tracer) les valeurs des paramètres utilisés (ci-dessous : “username”, “password”) lors de l’appel de la fonction. L’objectif étant de savoir si c’est bien les valeurs attendues.

Les commentaires

Les commentaires ne sont pas forcément requis si le code est fait correctement. Si on tient compte de la section des nommages plus haut, cela veut dire que les noms donnés sont déjà des commentaires en soit.

Cependant, il y a toujours des exceptions où les commentaires sont nécessaires.

Par exemple: pour noter les tickets de bugs, noter une solution de contournement (workaround), mettre les TODO ou les FIXME…

Le formatage de code

Formater un fichier c’est tout simplement afficher correctement son contenu afin de faciliter la lecture.

Si vous avez déjà codé dans votre vie, l’exemple suivante doit forcément vous parler:

“Oh p…ar Toutatis , je suis trop c.., c’était juste une indentation au mauvais endroit, mais cela m’a pris la journée pour la trouver”

L’indentation, c’est tout simplement des tabulations qu’on met devant les lignes de codes pour structurer son code.

Je n’imagine même pas les galères pour ceux qui codent en Python où les indentations sont encore plus importantes… 😱

Il y a des pratiques que vous pouvez appliquer par exemple:

• Terminer chaque ligne de code par une virgule, un point virgule, ou rien
• Terminer toujours un fichier avec un saut à la ligne
• Indenter correctement chaque ligne en fonction de sa profondeur dans la fonction
• Etc…

La factorisation de code

Pour écrire un code facile à comprendre et à modifier, il y a quelques éléments à garder en tête. Pour cela, le code doit:

• Être simple : Il faut éviter autant que possible de complexifier le code en se demandant si la solution implémentée est la plus simple pour répondre au besoin. Plus le code est simple, plus il est lisible, plus il sera maintenable dans le futur. Il y a un acronyme qui peut aider à vous rappeler ce principe : KISS (Keep It Simple Stupid).
• Être ciblé (focused) : Un bout de code doit être écrit pour résoudre une et une seule problématique. C’est valable à tous les niveaux d’abstraction du code : méthode, classe, package ou module. Le travail de réflexion autour du découpage du code doit permettre de déterminer les bonnes abstractions. Ainsi les responsabilités de chaque bout de code seront correctement réparties. On retrouve ici les principes SOLID notamment le “ Single Responsibility Principle”.
• Être testable : Si le code est simple et n’a qu’une seule responsabilité il devrait être facile à tester. Les tests constituent une sécurité contre les régressions qui peuvent intervenir lors de l’évolution du code. Dans le cadre du TDD (Test Driven Developpment), le code de test est même écrit avant le code de la fonctionnalité.
  Encore un acronyme qui caractérise les “clean” tests : FIRST (Fast, Independent, Repeatable, Self-Validating, Timely).
• Limiter les codes dupliqués: encore un acronyme DRY (Don’t Repeat Yourself). Néanmoins, deux bouts de codes peuvent être identiques, s’ils représentent des concepts différents.

Une expression de type : “J’ai fait du Refacto” => J’ai touché à un code qui marche (pas de bug forcément) pour essayer de l’améliorer.

L’application de ces points passe notamment par la factorisation de code.

Quand un code devient répétitif, il faut regrouper dans une fonction afin de pouvoir l’utiliser au besoin. Cela permet de faciliter la maintenance et donc quand le code évolue, on ne touche qu’à une seule fonction.

Prenons toujours exemple sur le login.

=> Code initial

=> Code factorisé

Conclusion

Le clean code n’est pas fait uniquement pour les Développeurs d’application mais pour toute personne qui écrit du code, incluant donc les testeurs automaticiens.

L’intérêt du “Clean Code” est d’anticiper l’augmentation de vos lignes de codes de tests automatisés. Cela vous permettra de gagner beaucoup de temps sur la lecture de code, la transmission de votre travail, la compréhension des tests, l’analyse des impacts de modifications, le débogage, les mis à jour, etc…

Plusieurs éléments peuvent être couvert avec le Clean Code notamment:

• Le nommage des fichiers, des classes, des méthodes et des variables
• Le traitement des erreurs
• Les commentaires
• Le formatage du code
• La factorisation de code

Cette liste n’est pas exhaustive, mais j’espère vraiment que ces astuces et principes vous aideront à améliorer la qualité de votre code de tests automatisés 😊

Que pensez-vous de cet article ?

Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !

À bientôt 😊