Bonjour à tous !
Dans ce billet nous allons nous intéresser aux tests. Vous avez sans doute entendu parler au cours de votre carrière ou sur les forums de TDD, de BDD… qu’est ce qui se cache derrière ses acronymes ? Comment les mettre en place ? Voyons ça de plus près !

Tout d’abord, je vais créer un projet en .NET 4.6.1. Pour ceci j’utilise Visual Studio 2017, avec l’extension SpecFlow. Je vais créer une solution FibonnaciApp qui contiendra :
– Une application console (.NET Framework 4.6.1) appelé FibonnaciApp
– Un projet de test (.NET Framework 4.6.1) appelé FibonnaciTest. Je lui ajoute directement une dépendance vers la dernière version de SpecFlow (à l’heure où j’écris ces lignes, la 2.4.0).

Vous devriez avoir ceci :

Commençons les choses sérieuses!

Pour résumer de façon concise, le TDD est une façon de programmer qui stipule d'écrire ses tests avant d'écrire la moindre ligne de code. Popularisé par Kent Beck au début des années 2000, cette pratique d'extreme programming promet un code plus fiable (on sait précisément ce qu'on va avoir besoin) et plus maintenable (si une amélioration doit être faite, on évite les non régressions). Pourtant, en 2018 force est de constater que beaucoup trop d'entreprises ne maîtrisent pas encore leurs process de tests…

Le TDD se fait en 3 étapes, parfois appelé RED/GREEN/REFACTOR :

• On va écrire notre test
  • Normalement il devrait générer une erreur, puisqu'aucun code n'a été implémentée pour le vérifier : c'est la phase « RED »
• On implémente notre code de manière à valider notre test
  • C'est la phase « GREEN »
• Maintenant qu'un test couvre la partie de code, on va essayer de la factoriser pour la rendre plus maintenable
  • Si un test devient rouge, on le corrige immédiatement : c'est la phase REFACTOR.

Comme indiqué précédemment, nous devons coder nos tests avant notre classe : ainsi nos tests seront automatiquement faux, nous ne serons pas influencés par le code que nous écrivons mais uniquement par le résultat attendu.

Nous allons typiquement créer une méthode int GetNumberIndex(int index). Nous pouvons donc faire un test :
– Qui vérifie que le paramètre index un entier positif ou nul, sinon on ne fait pas le calcul.
– Qui vérifie la valeur des deux premières occurrences (connues dans la suite de Fibonnaci), pour voir que notre formule est bien implémentée.
Une fois implémentée, on a donc ceci :

Si vous voulez, vous pouvez voir lancer les tests : la classe n’étant pas créé, cela va forcément planter. Maintenant, implémentons notre classe Fibonacci dans notre projet console !

Relancez les tests et admirez : ce n’est pas beau quand tout est vert ! Le TDD, c’est aussi simple que ça. Bien sûr je parle d’un projet simple avec une classe sans dépendances (ici pas de notion de Mocks), mais vous voyez le principe.

Encore moins répandu que le TDD, le Behavior Driven Development est une pratique de l’agilité apparu peu après le TDD par Dan North. Ici, on va tester comme son nom l’indique un comportement : la nuance avec le TDD est qu’en BDD on teste un parcours fonctionnel (on utilisera le moins de Mocks possibles) alors qu’en TDD on se base sur la technique (on teste uniquement la classe). De plus, les scénarii seront faites lors de séances avec le Product Owner, ils auront une forte valeur métier : d’ailleur, chaque scénario Gherkin (langage utilisé pour l’écriture des scénarii) doit être compréhensible par toutes les parties concernées (Développeurs, Qualification, Product Owner, Business Analyst, Métier…)

Le BDD se fait en plusieurs étapes :

On voit la carte avec le PO et le testeur, pour s'assurer que le besoin est compris.

• On écrit un scénario (qui sera rouge car pas encore codé)
• On écrit le code
  • Pour ça on part en TDD : on écrit un test unitaire, qui va être rouge
  • On le passe au vert
  • On refactorise
• On valide le scénario
• On refactorise

De cette manière, la logique métier sera dans les scénarii et le reste dans les tests unitaires : si vous faites dans ce sens, vous n'aurez pas de duplication de tests et une couverture de code optimale!

On va tout d’abord créer notre fichier Gherkin, avec le fichier SpecFlow Feature file (disponible si vous avez installé l’extension SpecFlow pour Visual Studio). Pour cela j’ai créé un dossier « Features » dans mon projet de test.

Maintenant on va copier les templates indiqués en faisant un clic droit sur l’une des étapes puis en cliquant sur « Generate Steps Methods », pour ensuite les mettre dans un fichier Steps.cs dans un dossier Steps fraîchement créé, qui contiendra toutes nos étapes. Vous devriez avoir ceci une fois votre classe remplie :

On voit qu’on a déjà couvert des tests qu’on faisait précédemment dans nos tests unitaires, qui avait une valeur plutôt fonctionnelle (si on peut parler de fonctionnel sur une fonction bâteau comme ça…), cool ! Maintenant implémentons le dernier test unitaire.

Puis notre classe, identique au premier exemple.
Comme vous le voyez, les résultats sont tous verts :

Cependant comme dis précédemment, 2 cas ne permettent pas de vérifier que notre fonction est bonne, surtout quand ce sont des cas bateaux et que l’entrée est égale à la sortie. C’est là que les BDD deviennent magique avec le Scenario Outline !

Ici, en un seul scénario on va spécifier les 11 premières occurrences. Ainsi, lors de l’exécution des tests, il va exécuter 11 fois le test avec des paramètres différents, et nous permettre d’avoir des tests plus fiables. On va générer l’étape, vu qu’elle a sensiblement changé, ce qui nous donne pour notre fichier Steps :

Ci dessous, le résultat

J’espère que vous en avez pris un peu plus sur la partie TDD/BDD, et que vous l’implémenterez dans vos futurs projets! Les sources de ce projet sont disponible sur mon répertoire Github.

A bientôt 🙂