Artisan logiciel Agile .Net / agile software craftsman in .Net
Membre de SigmaT/Agile Toulouse.
J'ai beaucoup travaillé pour des éditeurs logiciels dans divers secteurs d'activité.
Par le passé, j'ai eu à endosser autant le rôle d'architecte logiciel, chef de projet, responsable d'équipe ou de Scrum master tout en restant développeur.
Je suis resté en apprentissage permanent auprès de mes pairs, et ai aidé à développer des approches BDD chez différents éditeurs.
Trop souvent le BDD (Behavior Driven Development) est de suite relégué au rang de Test d'Acceptance (donc au niveau des IHM) et on écrit trop vite l'équation BDD = ATDD.
Je vous propose de découvrir la face caché de l'iceberg BDD, et par la pratique de SpecFlow, voir des exemples concrets de tests "unitaires" dirigés par le comportement qui viennent renforcer, voir même devenir la base de tous les tests de vos composants logiciels, quelque soit leur rôle.
Pour cela, une étape importante, sera celle du choix du langage (le fameux Domain Language) qui permet de décrire des comportements, ceux des composants logiciels, plutôt que celui des utilisateurs humains. Une réconciliation avec le DDD? (Domain Driven Design)