[ALT.NET] La reprise des Coding Breakfast !

Le petit-déjeuner le plus hype de la communauté .NET reprend du service !

Après une riche année 2014 qui a vu la multiplication des activités du groupe Alt.Net en soirée, Jeff et moi relançons la formule petit-déjeuner pour voir si ça intéresse toujours les braves, maintenant qu’il y a plein d’autres alternatives.

Comme le veut la tradition maintenant bien établie, je m’occupe du café, du sujet et des croissants et vous venez avez vos neurones et un PC (ou autre dispositif apte à la saisie de code) et son environnement de dev et tests.

A jeudi ?!

Damien et Jean-François 

— 

PS : pour ceux qui ignorent ce qu’est un Coding Breakfast, c’est une rencontre sympa en formule petit-déjeuner au cours duquel nous travaillons en paires sur un sujet de programmation court pendant 30 à 45 minutes avant de confronter nos solutions et de présenter nos idées en grand groupe.
On ouvre à 8h10 (café + causette) puis on démarre à 8h30 pile. Fin à 9h50 pour décollage et retour à votre boulot à partir de 10h.

Voir les coding précédents : http://blog.softit.fr/?tag=/Alt.net

[Formation] Comment passer du WebForms au MVC sans risque : ASP.NET MVC & Testing

L’ASP.NET MVC est la technologie web .NET depuis plusieurs années maintenant. Cette plateforme nous permet de mieux maîtriser le rendu HTML, le découplage métier/interface et surtout le testing.

Voici donc 2 sujets bien connus de l’équipe et qui tiennent à cœur à Soft’it : les applications web (ASP.NET MVC) et la qualité (testing).

Un de nos clients, Voluntis (éditeur de logiciels dans le domaine médical), a eu une problématique que grand nombre de sociétés rencontrent actuellement : comment passer de l’ASP.NET WebForms à l’ASP.NET MVC sans régression, et sans impacter les utilisateurs.

Même si une application WebForms fonctionne correctement depuis des années, il y a un moment où la dette technique devient un frein aux améliorations et vous coûte plus cher que les évolutions ne peuvent vous apporter.
Nous l’avons constaté avec tous nos clients, il est nécessaire de toujours prendre le temps de rester « aux goûts du jour » afin d’être en mesure de toujours proposer des nouveautés, et surtout de ne pas décourager vos développeurs en travaillant sur des technos « moins sexy ».

L’un des gros avantages du MVC est la facilité à appliquer du test sur la plupart des couches de votre application (Modèle, Contrôleur, voire Vue). Pourquoi ne pas utiliser cet avantage précis pour migrer sans risque ?!

formation-mvc-voluntisC’est sur cette base que nous avons construit une formation sur-mesure pour 10 développeurs/architectes de chez Voluntis :

  • jour 1 : introduction à l’ASP.NET MVC et aux bonnes pratiques, puis exemples de passage du WebForms au MVC
  • jour 2 : introduction à la notion de testing et comment tester une application MVC

La pratique étant le meilleur moyen d’apprendre, chaque jour fut composé en moyenne de 40% d’atelier !

Pour remplir cette mission, nous avons envoyé 2 membres de l’équipe Soft’it :

Marien Monnier
Rémi Lesieur-Bridel

Le résultat : une formation sur-mesure calée aux besoins de Voluntis, un travail exemplaire de Marien et Rémi, une équipe très satisfaite (4/4 au ROTI pour tout le monde) et un client ravi :

De plus, Erwan de Cadoudal (Team leader chez Voluntis, et demandeur de cette formation), nous a fait un témoignage très positif.

Si vous souhaitez faire une formation technique et/ou qualité sur-mesure, contactez-nous.

DevOps, le monitoring des applications Web comme point d’entrée


De nos jours, les applications web connaissent un boom incroyable. Tout le monde a compris qu’internet est un outil business très efficace qui permet d’augmenter la visibilité de l’entreprise (Marketing), étendre ses marchés (boutique en ligne),…etc.

Voici quelques chiffres sur la situation du commerce en ligne en 2013 :

  • Le nombre des acheteurs en ligne a augmenté de 5% en 2013.
  • La fréquence des achats en ligne est en progression avec une moyenne de 18 transactions par an et par acheteur, contre 16 en 2012.
  • Le nombre de sites marchands actifs a dépassé les 138 000.

* Statistiques avancées par  Elioweb (http://www.elioweb.com/statistiques-e-commerce-france.html)

Donc, contrairement aux débuts d’internet qui étaient constitués de sites vitrines essentiellement. On se retrouve, aujourd’hui, avec des applications Web capables de récolter et de capter les actions des utilisateurs.

Cette révolution a considérablement complexifié les applications Web : logique métier complexe, sécurité, performances…etc.

En outre, de plus en plus d’entreprises abandonnent le développement d’applications lourdes et les remplacent par des applications Web. Cela permet de réduire, voir d’éliminer, les processus de déploiement des applications et des mises à jour sur les postes utilisateurs.
De ce fait, les applications Web apportent un gain de temps considérable et une réactivité presque immédiate quand il s’agit de résoudre des bugs ou de déployer de nouvelles versions.

Du point de vue des équipes informatiques, l’enjeu est énorme. Les applications sont plus complexes, plus sensibles et ont un réel impact financier. Il faut donc avoir un niveau de qualité très élevé en même temps qu’une productivité accrue.

En général, les équipes informatiques sont organisées en plusieurs sous-équipes : les développeurs d’un côté et les opérationnels (administrateurs système, réseau, base de données, messagerie, etc…) d’un autre côté.
Les développeurs ont pour rôle de créer l’application et de la faire évoluer au fil du temps. Ils sont aussi responsables de la correction des éventuels bugs détectés. Les opérationnels, quant à eux, sont responsables de la mise en place des environnements techniques, du déploiement de l’application et du monitoring de l’infrastructure.

Chaque équipe possède ses propres méthodes de travail, ses propres priorités et ses propres métriques.
Cette organisation pose un réel souci pour la collaboration des équipes. Il n’est pas rare de rencontrer l’analyse suivante suite à un problème de performance, par exemple :

  • Admin réseau : « Pas de congestion, tous les routeurs fonctionnent ».
  • Admin système : « Les serveurs ont suffisamment de CPU et de mémoire ».
  • Devs : « Le code de l’application est bon, le même code fonctionne correctement sur l’environnement de pré-production ».

Au lieu de travailler ensemble pour identifier le problème, chaque équipe va analyser le problème de son point de vue et tenter de démontrer que « ça ne vient pas de chez nous »; voire dans certaines cas, essayer de mettre en cause les autres équipes. Mais, malheureusement, il y a bien un problème du point de vue des utilisateurs.

Ce genre de situation peut coûter cher à l’entreprise : perte de clients pour un site e-commerce, planification de stock erronée pour une usine, etc….

Afin d’éviter de tomber dans ce type de situation, une entreprise doit faire évoluer sa culture pour se concentrer sur l’humain, l’organisation du travail et le bon choix des outils de gestion du cycle de vie des applications et des infrastructures.

Cette culture est le cœur même de la philosophie DevOps visant à rapprocher les équipes Dev et Ops. Ce rapprochement permettra aux équipes de communiquer plus efficacement, de partager les mêmes objectifs et de réfléchir continuellement aux différentes pistes d’améliorations de leur travail.

La Journée DevOps Day, qui a eu lieu le 25 novembre 2014 à Paris, s’est penchée sur la problématique de mise en place du processus DevOps dans les projets informatique (voir l’article Tour d’horizon du Microsoft DevOps Day – « Infrastructure as Code » pour avoir une idée sur le contenu de cette journée).

La mise en place d’une culture DevOps au sein d’une entreprise nécessite un travail de sensibilisation et de conviction des équipes. Il ne s’agit pas d’installer un outil, mais de changer complètement les mentalités, la façon de travailler des collaborateurs voire même l’organisation des équipes. Toute tentative de mise en place d’une culture DevOps par simple décision émanant de la direction subira inévitablement un échec et engendrera plus de méfaits que de bienfaits ; la conduite du changement a une place prépondérante ici.

La notion de DevOps est une notion vaste qui couvre tout le cycle de vie d’une application, de son développement à sa mise en production en passant par les différents environnements techniques. Il est vital de mettre en place le processus DevOps de façon graduelle. Vouloir adopter ce processus dans tous les aspects du cycle de vie applicatif en même temps peut s’avérer complexe, voire même périlleux.

Un point d’entrée intéressant pour la mise en place de DevOps est le monitoring des applications déjà en production. Les équipes Dev et Ops pourront coopérer pour mieux réagir aux problèmes rencontrés sur les applications en production.
Le monitoring est, en fait, un bon point de coopération pour les Dev et les Ops. Un mauvais comportement d’une application engagera la responsabilité des Dev et des Ops en même temps. Si les deux parties sont convaincues qu’ils forment la même équipe, ils mettront toutes leurs compétences et leur énergie pour améliorer le processus de monitoring :

  • Choix des bons outils qui reflètent le réel état des applications.
  • Mettre à disposition des Devs des rapports afin qu’ils puissent anticiper les éventuels problèmes lors des prochaines versions.
  • Collaborer en temps réel pour la résolution des problèmes urgents
  • …etc

Se baser sur le monitoring pour une première mise en place de DevOps a pour avantage de démontrer l’intérêt de cette approche (applications plus stable, réaction plus efficace aux problèmes de production…etc.) et, donc, de faciliter son adoption pour les autres étapes du cycle de vie applicatif.

Cela-dit, il faut garder à l’esprit que le DevOps n’est pas un objectif en soi, mais une quête vers une amélioration continue de la collaboration des équipes Devs et des Ops.
La façon de mettre en place DevOps varie inévitablement d’une entreprise à une autre, voire même, d’un service à un autre au sein d’une seule et même entreprise. C’est un processus lent qui nécessite beaucoup de patience et une implication sans failles des différents acteurs.

Cependant, une fois sur les rails, DevOps apportera énormément à l’entreprise: des équipes soudées, un environnement de travail sain et des livrables de meilleur qualité, donc, des utilisateurs satisfaits [et il faut malheureusement trop souvent rappeler que c’est ce pourquoi nous travaillons tous].  

Introduction à la gestion des cycles de vie des applications (ALM)

Introduction à la gestion des cycles de vie des applications

(Application Lifecycle Management – ALM)

       ….

Evidemment, dit comme cela, cela peut paraître un peu abrupte voire déconcertant … Cycles de vie des applications  – Application Lifecycle Management. Mais sous ce nom se cache en réalité l’une des meilleures pratiques logicielles dont l’objectif est de fournir un logiciel de haute valeur et de haute qualité, et ce d’une manière très efficace, rapide et fiable

Quelles sont les différentes étapes de l’ALM ? 

D’un point de vue du développeur, il est courant de penser que le cycle de vie d’un logiciel commence et s’arrête lors du checkout et du commit des modifications du code. 

La réalité est tout autre, comme nous le voyons tous les jours, et couvre beaucoup plus. 

Le cycle de vie des applications commence à partir de la création du projet jusqu’à la livraison en production, comprenant plusieurs étapes dont le développement n’est qu’une petite partie parmi, entre autres, les tests, les documentations et la génération d’installateurs. 

L’ensemble de ces opérations permet de livrer un logiciel de haute valeur et de haute qualité pour le client.

Ce schéma montre le pipeline de déploiement idéal. On y retrouve l’ensemble des opérations automatisées à mettre en place lorsqu’on parle d’ALM.
Le processus est entièrement automatisé, capable de fournir un feedback détaillé de son statut et de celui de ses opérations, et de s’interrompre à chaque étape en cas de détection d’anomalies.
Bien loin de ce déroulement idéal, le plus souvent, il est fréquent que la plupart de ces opérations soient manuelles, partielles et sans fournir de réel feedback.
Même si maintenant il est largement admis que le code source doit être hébergé dans un outil de contrôle de version, et que chaque développeur doit faire des check-out et commit réguliers, il est encore très rare de trouver une plateforme d’intégration continue réelle automatisée, qui gère ne serait-ce que la compilation automatique et le déroulement des tests unitaires. 
A la place, il est fréquent qu’il y ait des flux allant dans toutes les directions, sources de risques et de problèmes à venir, comme le montre le schéma ci-dessous  : 

Quel est le problème avec la livraison de logiciels ? 


  1. Les opérations sont nombreuses, souvent manuelles et sur différents environnements techniques mal maitrisés,
    • Le corollaire est que ces opérations dépendent de quelqu’un (responsable déploiement, chef de projet, expert quelconque). La question est donc : que se passe t’il lorsque cette personne est absente
    • extrêmement répétitives, ces tâches sont une plaie sur le long terme,
    • la réalisation d’une documentation souvent lourde est nécessaire,
    • une courbe d’apprentissage lente pour l’ajout de nouveaux membres à l’équipe,
    • des besoins humains supplémentaires sont nécessaires à l’équipe

  2. Le code source et les paramétrages ne sont pas nécessairement stockés dans le même endroit, mais peuvent être générés à partir de partout et par n’importe qui, n’importe quand : qui contrôle quoi ?
  3. Aucune vraie traçabilité,
  4. Des délais de livraison très long : il peut se passer des jours entre la validation et le déploiement,
  5. Des erreurs sont plus enclines à apparaître. 
En bref : lorsqu’il y a des opérations manuelles, il devient vraiment difficile de répéter, de cadencer et de mesurer la livraison. 

Quels sont les objectifs de l’ALM ? 

Comme vous l’aurez compris maintenant : implémenter l’ALM c’est principalement se concentrer sur l’automatisation de la grande majorité (sinon la totalité) des opérations ; afin d’assurer la création de valeur et des livraisons fiables, rapides et cadencées.
L’idée maîtresse est de réduire les temps de cycle.
Plus le temps de cycle est court, plus le client pourra être satisfait (par plus de fonctionnalités ou même par des corrections de bugs). L’objectif est de favoriser les feedbacks rapides.

Comment? 

Etant donné que cet article est seulement une (très) courte introduction, nous ne plongerons pas plus à fond dans les détails ici. 
Nous énumérerons simplement les différents sujets à couvrir. Ceux-ci seront expliqués plus en détails dans de prochains articles :
  1. Configuration et installation d’un outil d’intégration continue (TFS, Hudson, CruiseControl), 
  2. Mettre au cœur de l’outil l’analyse de qualité (règles de gestion, Sonar, FxCop) ainsi que les tests, le tout avec de l’automatisation, 
  3. Mettre sous contrôle de source tous les paramètres ou fichiers de configuration pour tous les hôtes cibles, 
  4. Lister toutes les autres opérations manuelles, les automatiser et les chaîner entre elles,
  5. Modifier le processus de développement pour s’appuyer davantage sur les tests d’acceptation,
  6. Réduire les délais de feedback (testeurs, clients ….). 

Conclusion 

Cet article n’est que le premier d’une série d’articles introduisant les principes de ALM (intégration continue, déploiement continu…etc). Il vise à présenter simplement ce qui est en jeu tout en abordant les grands principes du cycle de vie des applications.
Dans les prochains articles, nous expliquerons plus en détail avec de cas concrets d’utilisation et d’implémentation, les scénarios de mise en place de l’ALM.

Liens utiles

ALM (sur wikipedia) : pour une explication simplifiée.
Intégration Continuela définition par M. Martin Fowler
Déploiement Continu : la définition par M. Martin Fowler

Le chemin vers la qualité est-il unique ? (Part 1 : la Méthodologie)

le chemin 1

Scrum, Crystal Clear, eXtreme Programming (XP) … De plus en plus, nous nous éloignons du cycle en V. Ou en tout cas, nous essayons de le faire.

Pourtant, si l’on se rappelle la conférence « Petite histoire d’une méthodologie agilement établie » donnée à Paris Web, ce n’est pas si vrai que ça. A la question « Combien d’entre vous n’appliquent pas d’agilité dans leur entreprise ?« , un bon nombre de mains se sont levées.

Incidemment, la question qu’on a pu entendre était « Quelle est la vraie bonne méthodologie à appliquer ?« .

Et Alexandre Jakubiak tout comme Julien Oger -tenant la conférence citée plus haut- se sont bien gardés de donner une réponse toute faite. Ils ont même prévenus l’audience qu’ils nous présenteraient « la solution qui leur correspondait le mieux ». Ce qui remet beaucoup de choses en perspectives.

Tout d’abord, ils ont voulu bien évidemment éviter le cycle en V. On comprend très vite ses limites avec la fameuse phrase client : « C’est bien ce que j’ai demandé, ce n’est plus ce que je veux. » (i.e. la lenteur de cette méthodologie fait que les besoins du client vont évoluer avant qu’il ait pu mettre la main sur la solution).
Mais rejeter cette méthodologie en bloc n’est pas nécessairement productif non plus : son approche prédictive (bien que trop orientée projet) a ses vertus.

Opposées, la ou les méthodologies agiles, considérée plus réactive intégrant notamment le client plus tôt au processus de développement. Son principal inconvénient reste le nombre de solutions déjà existantes.

Première chose : éviter à tout prix le Big Bang. Mettre en place Scrum -par exemple- dans son ensemble (outils et pratiques) d’un coup au sein de son équipe est suicidaire. Au mieux, on retournera au cycle en V (plus rassurant car déjà connu) en un sprint. Au pire, l’équipe implosera.

La solution choisie a été d’y aller progressivement. Surtout de préalablement faire un tour de l’existant, regarder ce qui serait le plus simple, qui apporterait le plus… et le plus simplement en interne.
Leur conclusion fut de partir de Crystal Clear puis de piocher dans toutes les méthodologies existantes ce qui leur correspondait et les implémenter au fur et à mesure.

Tout ne fut pas simple de l’aveux même de ces messieurs. La méthodologie parfaite n’est qu’utopie. Il faut, dans la mesure du possible, rester souple et ouvert à l’évolution. De même, chaque équipe, chaque société a des besoins différents.
Cela peut être lié à la taille de l’équipe, des projets, des langages utilisés ou même de l’expérience (on fera passer plus facilement de jeunes développeurs à une nouvelle méthodo que des seniors habitués au bon vieux V).

Chez Soft’it, nous utilisons Scrum en interne, notre Scrum. Nous avons dû adapter certaines règles pour que notre fonctionnement soit plus limpide : il n’y a pas de Scrum Master fixe par exemple, il change à chaque Sprint. Cela permet de responsabiliser chaque personne travaillant sur les projets et en plus de ne pas laisser cette pression toujours sur les épaules d’une même personne.

Nous appliquons également plusieurs pratiques de l’eXtreme Programming (XP) : le « Pair Programming« , par exemple, pour les nouveaux arrivants et sur des phases un peu complexes; ou la revue de code (« Code Review ») après chaque story réalisée.
Nous faisons également du testing et avons une usine logicielle pour l’intégration continue. Cependant, la TDD (« Test Driven Development », également part d’XP) n’est pas une obligation chez nous.

S’arrêter à une méthodologie et l’appliquer « By the book », même le cycle en V, est impossible. Le faire est source de frustration ou de goulot d’étranglement bien plus que de facilités dans un projet.

Savoir écouter les besoins en interne et externe, tirer le meilleur de ses retours d’expérience heureux et surtout malheureux, vous guidera bien plus vers votre méthodologie qu’un livre à appliquer à la lettre.

L’agilité contient un principe fondamental : l’amélioration continue. Pensez à réserver du temps pour prendre du recul sur votre organisation, et à construire ensemble la méthodologie qui vous correspond.

[Formation] Testing et TDD en Java…

Un des membres de l’équipe Soft’it – Rémi Lesieur pour ne pas le nommer – a réalisé lundi et mardi dernier une formation Testing/TDD à destination d’une équipe expérimentée en Java, pour une division de l’Armée française.

L’objectif de la formation était double: présenter ce qu’est le testing et la TDD (philosophie et théorie), tout en démontrant l’intérêt ainsi que le gain de temps et de la qualité.
Eh oui, c’est souvent difficile en tant que développeur de se dire qu’écrire du code pour tester du code, ça revient à gagner du temps! C’est pourtant bien le cas.

Rémi a donc abordé la logique du testing d’une manière générale en démontrant que ce n’est pas parce qu’on teste à la main, que notre code est bon et surtout pérenne (régressions non visibles).
Puis il a présenté les différents types de tests (unitaires/intégration), ainsi que la notion de mocking (voir « Dummy, Fake, Stub, Mock et Spy, les tests unitaires avec l’aide de Moq.« ).

Pour finalement attaquer le testing dans l’eXtreme Programming (XP) : le Test Driven Development (TDD).

Au total, 2 jours pour 10 développeurs/lead-techs mélangeant théorie et beaucoup de pratiques sous forme de Katas, en pair programming.

Un bon succès puisque 7 personnes sur 10 ont donné la note de 5/5, et les 3 restantes, 4/5. La formation construite sur mesure par Rémi a donc visé juste.

Si vous êtes intéressé par des formations et/ou du coaching sur du testing (et tout autre outil/méthodologie autour de la qualité), dites-le nous!

[BDD] Introduction au Behavior Driven Development

Introduction à la BDD

J’ai récemment pu expérimenter au cours d’une mission auprès d’un client la méthodologie BDD, autrement dit « Behaviour Driven Developement » (développement dirigé par le comportement). J’ai trouvé cela fort intéressant, du coup je me suis intéressé au sujet. 

Ce post aura pour objectif de revenir sur la notion de BDD, d’en présenter les principales grandes lignes ainsi que de suivre la méthodologie à travers un exemple.

BDD

Le processus BDD met en avant le langage naturel et les interactions dans le processus de développement logiciel. Les développeurs utilisant le BDD utilisent leur langue maternelle […] pour décrire l’objectif et le bénéfice de leur code. Cela permet aux développeurs de se concentrer sur les raisons pour lesquelles le code doit être créé […]. 
Définition Wikipédia de BDD

La notion de BDD fut introduite par Dan North, en réponse aux nombreuses critiques formulées à l’encontre du TDD (développement dirigé par les tests), en particulier concernant les difficultés de compréhension entre le programmeur et le chargé fonctionnel.

En effet au cours de projets en TDD, il m’est souvent arrivé de me demander par quel test je devais commencer, ce que je devais tester et à contrario ce que je ne devais pas tester, et surtout comment je devais tester. La méthodologie BDD est censée apporter des solutions à ces interrogations. 

Ses principes sont évoqués ci-dessous :

  • Définir les comportements de l’application avec des notations compréhensibles par tous : chargés fonctionnels et développeurs.
  • Chaque morceau de code est implémenté pour satisfaire un comportement de l’application, ceci afin de développer uniquement ce qui est utile à l’application.
  • Les exigences définissent les tests et le comportement de l’application. Elles sont définies à travers un canevas « Etant donné que … Lorsque … Alors ».

Ne vous y trompez pas, BDD ne réinvente pas le TDD, il s’appuie dessus et y ajoute des notions permettant une meilleure compréhension et définissant un fil conducteur pour le développeur.

Concrètement, qu’est-ce que cela donne ?

Imaginons le cas d’une application embarquée dans un automate pour la vente de billet de train. Je veux pouvoir définir la possibilité d’acheter des billets pour Londres.

Le chargé fonctionnel définit les comportements attendus ainsi :

Exigence 1 : 

Etant donné qu’il reste de la place dans le train pour Londres
Et ma carte bancaire est valide
Et j’ai suffisamment d’argent sur mon compte
Lorsque je valide l’achat d’un billet pour Londres avec ma carte bancaire
Alors je reçois une confirmation de la transaction
Et j’obtiens 1 billet pour Londres
Et j’obtiens le reçu de ma carte bancaire
Et mon compte est débité du montant du billet

Exigence 2 :

Etant donné qu’il reste de la place dans le train pour Londres
Et le montant du billet est de 40€
Et j’ai un billet de 100€
Lorsque je veux acheter 1 billet pour Londres avec mon billet
Alors je reçois une confirmation de la transaction
Et je reçois 1 billet pour Londres
Et j’obtiens un remboursement d’une valeur de 60€

Exigence 3 :

Etant donné qu’il reste de la place dans le train pour Londres
Et ma carte bancaire est valide
Et je n’ai pas suffisamment d’argent sur mon compte
Lorsque je valide l’achat d’un billet pour Londres avec ma carte bancaire
Alors je reçois un message m’indiquant que la transaction a échoué

Exigence 4 :

Etant donné qu’il reste de la place dans le train pour Londres
Et le montant du billet est de 40€
Et j’ai un billet de 20€
Lorsque je veux acheter 1 billet pour Londres avec mon billet
Alors je reçois un message m’invitant à compléter le reste de la somme ou à annuler la transaction

La question que le développeur se pose est « par où commencer » ? 

La méthodologie BDD préconise de prioriser en choisissant le comportement le plus important.
Ici, dans le cas de l’automate, j’ai pris l’option de l’opération la plus fréquente; soit le paiement par carte. Je ne retiendrai donc que les exigences 1 et 3.
De manière générale, la décision est prise en concertation avec le chargé fonctionnel. Le choix se porte le plus souvent sur la valeur business la plus importante. La question simple à se poser, est : Quelle est la fonctionnalité la plus importante qui manque actuellement à mon application ?. Bien entendu cela dépend du contexte du projet, dans le cas de mon automate, la fonctionnalité la plus importante est le paiement par carte de par sa fréquence.

L’exigence est alors traduite au travers d’un test d’intégration par le développeur. Un test qui échoue, bien entendu (principe même du TDD). 

 

Le nom du test doit être compréhensible par tous, on construit alors son nom par une phrase décrivant le comportement du test tel « Acheter un billet pour Londres avec ma carte bancaire et avec assez d’argent sur mon compte ». La phrase doit couvrir l’intégralité du comportement. 

Chaque étape du scénario devra être implémentée par la suite par le développeur. Les étapes « Etant donné que » (ou « Given ») permettent de définir le contexte initial du test, l’étape « Lorsque » (ou « When ») indique le déclencheur du comportement et les étapes « Alors » (ou « Then ») sont chargées de vérifier si l’application a bien répondu au déclencheur. 

 

J’utilise l’outil SpecFlow, disponible dans les packages nugget, qui fournit une interface pour suivre la méthodologie BDD à partir de Visual Studio. Il fournit également le squelette de la méthode de test (voir ci-dessus) que le développeur devra implémenter. Remarquez le nom des méthodes qui reprenne l’intitulé des étapes. 

Je ne vais délibérément pas détailler l’utilisation de SpecFlow, ce n’est pas le sujet, cela se fera peut-être dans un autre post.

A ce moment, l’application ne possède pas encore d’entité Banque pour indiquer qu’une carte bancaire est valide, confirmer une transaction, ou bien d’entité Gare pour permettre l’achat d’un billet. On utilise alors des bouchons (ou mocksvoir le post suivant pour plus d’information) afin de combler l’absence de ces entités. 

Le test d’intégration est toujours en échec. 

Je cherche à faire passer mon test d’intégration, pour cela je mets en place des tests unitaires propres à mon entité Banque. Ces entités prendront la responsabilité d’un comportement.
La convention veut que l’on place le mot préfix « doit » (should en anglais) devant le nom des méthodes de test. On pourrait ainsi lire un test par « Mon entité Banque doit valider ma carte bancaire » pour la méthode « DoitValiderMaCarteBancaire » de ma classe « BanqueTest ». Cette convention a un objectif: celui d’inciter le développeur à ne pas se disperser. Il doit en effet constamment se poser la question: est-ce que ce test s’applique à cette entité ?

Je dois à présent créer mon entité Banque afin que mon test unitaire passe également. Je le développe avec dans l’esprit l’idée de faire toujours au plus simple (principe YAGNI). Si mon entité Banque doit accéder à une couche de donnée « BanqueDAL », je mets en place des tests unitaires pour ma couche d’accès aux données, je créé ensuite l’entité « BanqueDAL » afin de satisfaire aux tests.

Une fois mes tests unitaire passés, j’effectue une refactorisation de mon code si besoin, et je lance mon test d’intégration. Celui-ci ne passe pas; chose normale vu que je n’ai pas non plus mon entité Gare. 

J’itère ainsi à créer mes tests unitaire d’entité jusqu’à ce que mon test d’intégration passe

Lorsque mon test d’intégration passe, je lance tous mes tests, et j’observe ou non des erreurs.

Si j’en obtiens, il y a trois possibilités :

  • J’ai introduit un bug, donc je le corrige
  • Le comportement attendu est toujours pertinent, mais s’est déplacé ailleurs. Je déplace le test et je le modifie éventuellement
  • Le comportement n’est plus correct, donc je supprime le test

Dans le cas où je n’ai pas de régression, j’itère sur un nouveau comportement, et donc un nouveau test d’intégration. Par exemple celui de l’exigence 3.

Le cycle se poursuit jusqu’à couvrir tous les comportements de l’application. 

Pour en savoir plus :

http://dannorth.net/introducing-bdd 

http://referentiel.institut-agile.fr/bdd.html

http://www.specflow.org

http://fr.wikipedia.org/wiki/Behavior_Driven_Development

http://blog.stevensanderson.com/2010/03/03/behavior-driven-development-bdd-with-specflow-and-aspnet-mvc/