Accueil > .NET, Cloud, Devops, Méthodes Agiles, Outillage > Cas concret d’agilité avec BDD (Gherkin Cucumber), une usine logicielle TFS déployant sur MS Azure et SpecFlow

Cas concret d’agilité avec BDD (Gherkin Cucumber), une usine logicielle TFS déployant sur MS Azure et SpecFlow

BDD (Behavior Development Driven) et TDD sont des sujets « classiques » pour certains et mystérieux – voir dangeureux / incompréhensibles – pour d’autres!

Mon post d’origine date de 2011 où à l’époque, je n’avais pas un VSO et Azure pour être aussi Agile qu’aujourd’hui !

Sans entrer dans les débats existanciels et stérils, voici un témoignage d’un véritable projet où BDD est mis en place.

OBJECTIF: A partir de spécifications “classiques” assez « riches », nous allons :

  1. [Responsable Fonctionnel] Transformer cela en spec BDD,
  2. [Responsable Fonctionnel] L’écrire dans l’outil Microsoft TFS / VSO, via Excel
  3. [Développeur] Implémenter le code de test (guidé par la structure BDD auto-générée),
  4. iSe questionner vis-à-vis des spécs et faire des aller-retours aux responsables fonctionnels pour aboutir à un langage commun sans confusion ni d’interprétations possibles.
  5. [Responsable Fonctionnel et développeur]  conviennent des ajustements aux spec BDD
  6. [Développeur] Implémentation des tests
  7. [Développeur] Implémentation du code
  8. [Développeur] Refactoring
  9. [Développeur] Prouve au  Responsable Fonctionnel que sa « Définition Of Done » basée entre autre sur le « Given-When-Then » du BDD est respecté
  10. [Développeur]  Dans notre exemple, où il est critique d’avoir une couverture de code à 100%, lancement des outils de Couverture de code
  11. [Responsable Fonctionnel] Micro-évolution des specs, et cela provoque des tests qui « cassent »

VOICI LES SPECS
Ecran Rôle Profil
Visiteur Manager User central Admin tech
Ecran d ‘accueil Navigation x x x x
Activité prévisionnelle Lecture x x x x
Saisie x x x
Export csv x x x x
Performance Lecture x x x x
Import & Export Lecture x x
Lancement import x x
Lancement export x
Utilisateurs Lecture x x x
Création / Modification x
Paramètres Lecture x x
Saisie alertes x x
Saisie paramètres généraux x
Saisie paramètres généraux x

ETAPE 1: Reformulation du tableau précédent (ainsi que des autres fonctionnalités) en formalisme BDD,
et cela directement dans EXCEL (connecté bi-directionnellement à Microsoft TFS / VSO)

Si on n’aime pas Excel et on préfère MS Project, Word ou le portail Web de TFS, on utiliser ces dernier indifféremment (qui sont également bi-directionnellement connectés à TFS). Ci-dessous, via le portail Web:

ETAPE 2: Zoom sur la transformation du tableau précédent en formalisme BDD
(affiché avec IntelliSense dans Visual Studio avec Add-on SpecFlow, donc on ne peut pas écrire n’importe quoi comme Spec, car c’est compilé par VS)

ETAPE 3: Le développeur implémente les tests unitaires à l’intérieur de la coquille auto-générée par SpecFlow

En suivant la méthodo « Red, Green, Refactor » (SUPER important de la respecter scrupuleusement à la lettre, sinon, on peut créer des tests qui passent toujours ou négliger la partie « refactoring »),

  1. J’écris les tests dans la coquille BDD que outil m’a généré. J’aboutit à un teste échoué (Red) {normal ,je n’ai pas de code}.
  2. J’implémente ma 1ière idée de code pour faire passer les tests en Green (non refactorisé, donc potentiellement encore crados)
  3. Dans mon cas, le premier bout de code est tellement moche que je ne peux archiver le code dans TFS !! avec des alertes de mon IDE dans tous les sens !!
    Ca tombe bien, c’est la dernière étape avec du Refactor.

BENEFICE 1 : Refactorisation

Cette refactorisation me force à passer :

–          de mon code crados : Maintenability Index très faible 20 (donc non maintenable! i.e. code de stagiaire pas bon) et une Complexité cyclomatique de 105  (donc code très complexe) ;   i.e. personne au monde ne voudrait maintenir mon code, avec 105 lignes de code, car les combinaisons du tableau sont importantes (mais c’est une « fausse excuse » qui ne justifie pas un code non maintenable)

–          à un code moins crados (Maintenability Index = 59 ; Complexité cyclomatique de 63) qui me permet enfin d’archiver mon code dans TFS / VSO

–          à un code maintenable qui tiens dans ½ écran (Maintenability Index = 72 donc bien plus maintenable ; Complexité cyclomatique de 28 donc faible complexité).
Rappel:  « RedGreenRefactor » me rappelle que ce code n’est pas (et ne sera peut-être jamais parfait) et que cela n’est qu’une réponse et non LA réponse à un problème particulier.

BENEFICE 2 :

Le code est centralisé. Ca semble évident, mais il n’est pas rare de voir cette logique éparpillée dans les écrans IHM et/ou dans plusieurs endroits du projet.

BENEFICE 3 :

Le code est protégé (100% de couverture de code dans mon code ci-dessous), et la moindre modification de spéc à l’avenir sera détectée et l’usine logicielle TFS/VSO nous préviendra !

BENEFICE 4 : Tout est intégré à Visual Studio et Microsoft Team Foundation Server (TFS) ou Visual Studio Online (VSO), avec du déploiement continue sur …. Microsoft Azure

La moindre modification des spécifications (en respectant des processus pour éviter le chaos) sera identifiée par les tests unitaires, et le % de couverture de code

BENEFICE 5: Centralisation dans TFS/VSO de TOUTES les spécifications, et génération automatique de la spec pour le client !!

BENEFICE 6: Et les specs, vous les avez lus ??

Les Spec font partie de la « Definition Of Done » (DoD) et surtout minimalistes (donc pas d’explications redondantes) et compilées par le moteur BDD (donc, on ne peut pas écrire n’importe quoi !).

Categories: .NET, Cloud, Devops, Méthodes Agiles, Outillage Tags:
  1. Pas encore de commentaire
  1. Pas encore de trackbacks


4 − un =