Catégorie : Pratiques de codage

(Behavior-Driven Development) ou développement dirigé par le comportement

L’approche BDD vise spécifiquement à améliorer de manière significative l’efficacité de la collaboration entre les différents rôles impliqués dans un projet.

Tout comme mes articles sur le Clean Code et le TDD, voici une nouvelle synthèse :

Le 3 Amigos

1. Une personne capable de représenter le besoin
2. Une personne capable de représenter la mise en œuvre
3. Une personne capable de challenger les deux autres.

Atelier de spécification, d’expression du besoin. sous forme de scénario.

Les exemples doivent être exprimés dans le language métier, éviter d’utiliser des termes techniques.

Des exemples auto-suffisants.

Conservation des notes prises.

Compléter les scénarios inversé (ex: Pas de remise si inférieur à 50$, remise au dela de 50$, ici nous avons deux scénarios pour un besoin)

Automatisation des scénarios

La syntaxe Gherkin

Utilisation des étapes :

Exemple : Given When Then

On peut ajouter And et But

On peut remplacer par des termes français

Given → Étant donné que ou Sachant que ou En tant que

When → Quand ou Lorsque

Then → Alors ou Donc

Ce système peut servir pour l’écriture des tickets et des tests

Quelques nom d’outils d’automatisation : Cucumber, Behat.

Utilisation de Persona, DataSet et DataBuilder

Avant de poursuivre, je vous invite à consulter mon article dédié au TDD.

Il s’agit également d’une prise de notes inspirée du livre Software Craft. Voici mon résumé synthétisé :

N’importe qui peut écrire du code que l’ordinateur comprend; seuls les bons développeurs écrivent du code que les humains comprennent.

Les questions à se poser

• Le code n’est-il pas trop complèxe pour ce quíl fait ?
• N’est-il pas possible de le simplifier ?
• Les abstractions et autres généralisations introduites le sont-elle à bon escient ?
• Est-ce qu’on anticipe pas trop sur un possible futur ?
• Est-ce qu’on comprend à la première lecture ce que le code cherche à faire ?
• Le code ne tend-il pas à se répéter ? Est-il pertinent d’en réduire la duplication ?
• le design mis en place autorise-t-il suffisamment de liberté pour la suite ?

Les règles du clean-code

• Rester simple et aller à l’essentiel.
• Révéler l’intention du code
• Découper les fonctions
• Respecter l’art du naming
• Respecter l’art du Storytelling
• Lorsque l’on modifie du code existant, il doit être mieux écrit que précédemment.
• Respecter les règles de structure de code (Formatage, Respect des standards, Indentation, )
• Respecter les niveaux d’abstractions (une fonction enfant doit être en dessous de celle qui l’appelle)
• Ne pas contourner la règle d’une seule sortie de paramètre par fonction, Si la valeur est complèxe on l’encapsule dans un type dédié.
• Restraindre le nombre de variable, et le définir au bon endroit
• Commenter du code si il y a une subtilité, pour aider à comprendre le code; Marquer des problèmes à résoudre (ex : Todo); Apposer des mentions légales.
• Appliquer ces règles au test.
• Passer les tests

Naming

• Privilégier les nom communs pour les classes et les verbes pour les méthodes.

Anti-Pattern

• Acronymes et Abréviations, sauf si le terme fait parti du champ lexical du projet.
• Termes fourre-tout (ex : Data, Info, Manager, Service) cela rajouter du bruit inutile.
• Utilisation du Paramètre* (ex : GetArrrayOfProduct → GetProducts)
• Les noms trop court (ex : i → index)
• Paramètres* ou d’argument identique au type (ex : string str)
• Nom trop long, si il est trop long c’est qu’il est possible de découper

Acronymes à garder à l’esprit :

• KISS → Keep It Simple And Stupid
• YAGNI → You Ain’t Gonna Need It
• TDD → Test Driven Development
• DRY → Don’t Repeat Yourself

*Paramètre → type de sortie (return) d’une fonction

Récemment, j’ai découvert un livre passionnant intitulé Software Craft. Fruit de la collaboration entre Cyrille Martraire, Arnaud Thiéfaine, Dorra Bartaguiz, Fabien Hiegel et Houssam Fakih, cet ouvrage plonge au cœur de l’artisanat logiciel. Il explore avec finesse les principes, les pratiques et l’état d’esprit nécessaires pour créer des logiciels de qualité, en mettant l’accent sur des valeurs clés comme la collaboration et l’amélioration continue.

Suite à cette lecture inspirante, j’ai pris des notes synthétiques dans mon espace Notion, que je vous partage ici :

Les trois règles du TDD :

1. On doit écrire un test qui échoue avant d’écrire n’importe quel code de production.
2. On ne doit pas écrire plus de tests que ce qui est nécéssaire pour échouer ou ne pas compiler.
3. On ne doit écrire que le code suffisant pour que le test actuellement en échec réussisse.

Les 3 étapes (Itération) du TDD :

1. Red (Le test ne passe pas)
2. Green (Le test passe)
3. Refactor (Amélioration du code pour une meilleure lisibilité)

L’étape 3 est requise seulement si il y a besoin d’une refactor

La rigueur de chaque étape est nécessaire pour performer dans le TDD.

Remarque : utiliser la règle de triangulation afin d’éviter les valeurs de retour en dur dans le code. Cela consiste à toujours écrire au moins deux tests avec des valeurs différentes. Cependant on ne doit pas le faire dès la première itération. le premier test doit être validé puis un nouveau test est écrit puis échoue ou ne compile pas.

Les règles d’écritures d’un test

Anatomie d’un test :

Concerne le nommage des fonctions de test et/ou des classes.

1. should/when (ex : Should_raise_an_error_when_denominator_is_zero)
2. given/when/then (ex: Given_five_as_nominator_and_zero_as_denominator_when_I_divide_nominator_by_denominator_then_an_error_is_raised)

Corp d’un test :

Règle du triple A : Arrange/Act/Assert.

La règle du triple A est une méthodologie de base pour écrire des tests unitaires pour un scénario unique. Elle est divisée en trois sections distinctes. La première section, « Arrange », implique la configuration du test. C’est ici que vous initialiserez les objets, définirez les valeurs ou entrerez les données nécessaires au test. La partie « Act » fait référence à l’exécution de l’action qui doit être testée, tandis que « Assert » est la phase où vous vérifierez si le résultat de l’action est le résultat attendu.

Écrire du code qui ne compile pas n’est pas intuitif mais avec la méthode TDD on apprend à lâcher prise et utiliser la puissance de l’IDE pour générer le code attendu.

Voici le code source d’un exemple ou chaque commit représente une étape du TDD : https://github.com/adrunor/FizzBuzz