111 lines
4.6 KiB
Markdown
111 lines
4.6 KiB
Markdown
# Recette et maintenabilité
|
||
|
||
|
||
## Chaque recette fonctionnelle peut être automatisée
|
||
|
||
La démarche et la syntaxe du Développement piloté a l'avantage d'être
|
||
claire et de faciliter la communication.
|
||
|
||
|
||
J'ai une excellente nouvelle pour vous : **cette syntaxe va vous
|
||
permettre d'automatiser la recette de votre application**. Vraiment !
|
||
|
||
|
||
Et je ne vous parle pas d'outils, si vous en avez déjà utilisé, qui
|
||
vont enregistrer puis reproduire les clics et saisies que vous faites
|
||
sur une page web (comme avec [Selenium](seleniumhq.org/...)). Non, surtout pas !
|
||
Je vous parle d'outils pour lesquels vous n'avez rien à faire...
|
||
|
||
|
||
Après tout, **si vous avez fait l'effort de respecter une syntaxe
|
||
spécifique pour décrire vos Scénario, un programme informatique doit
|
||
être capable de les interpréter**.
|
||
|
||
|
||
Il existe aujourd'hui deux principaux outils sur le marché : Cucumber et
|
||
Behat. Le choix de l'outil dépendra du socle technique choisi par vos
|
||
développeurs pour votre Projet.
|
||
|
||
|
||
Concrètement, ces outils vont transformer vos Scénarios en code
|
||
informatique. Ce code informatique sera adapté par vos développeurs qui
|
||
lui donneront un sens et s'assureront qu'il signifie bien ce que vous
|
||
avez demandé.
|
||
|
||
|
||
Par la suite vous disposerez d'une interface où chaque fonctionnalité,
|
||
chaque scénario et chaque étape seront, ou bien verte (terminée), ou bien
|
||
jaune (pas encore développé), ou bien rouge (ne répond pas au besoin
|
||
initial).
|
||
|
||
|
||
|
||
|
||
Utiliser de tels outils a un coût puisqu'il exige un travail de
|
||
traduction par l'équipe technique. Ce coût peut être important, cela
|
||
peut demander du temps non négligeable, en plus d'une montée en
|
||
compétence des équipes techniques (très rapide en général),
|
||
|
||
|
||
Cependant, en utilisant ces outils :
|
||
|
||
+ Les équipes techniques savent si oui ou non elles ont répondu au besoin
|
||
+ Les équipes techniques sont rassurées dans leur travail
|
||
+ Vous connaissez exactement l'avancée de votre projet
|
||
+ Vous pouvez sans risque gérer votre besoin de changement : si une autre fonctionnalité est "cassée" par ce changement, vous le savez tout de suite et pouvez agir en conséquent
|
||
+ Vous augmentez le niveau de qualité de votre projet. C'est autant de gains lors de la vie du Produit et de sa maintenance, qui sans cela peut être très coûteuse
|
||
+ Vous-même savez en un instant si le livrable est conforme à vos attentes
|
||
|
||
|
||
Rien ne vous oblige à utiliser ces composants d'automatisation de
|
||
recette. Ne pas les utiliser peut certes être dommage, mais n'enlève
|
||
rien à la démarche générale.
|
||
|
||
|
||
>Facilitez le changement en automatisant la recette fonctionnel
|
||
|
||
## Assurez-vous que les équipes techniques automatisent leurs recettes techniques
|
||
|
||
Tester automatiquement qu'un livrable correspond à vos **attentes**
|
||
fonctionnelles c'est bien ; mais être certain de la **fiabilité** de
|
||
votre produit c'est encore mieux !
|
||
|
||
|
||
La pratique du développement piloté par le comportement, c'est-à-dire de
|
||
tout ce que l'on a présenté ici (les fonctionnalités, les scénarios...)
|
||
nécessite quelque chose de fondamental : que **vos équipes mobilisent
|
||
leur énergie sur votre besoin, pas sur leurs bugs**.
|
||
|
||
|
||
Pour cela il n'y a pas énormément de solutions : **vos équipes
|
||
techniques doivent créer des tests automatisés de leur code source**.
|
||
|
||
|
||
C'est un impératif fort : c'est le seul moyen pour qu'elles ne vous
|
||
disent pas "nous ne pouvons pas développer cette fonctionnalité, c'est
|
||
impossible car on risque de casser tout l'existant et d'introduire des
|
||
bugs". Non, avec des tests automatisés, une équipe compétente ne peut
|
||
pas vous répondre ça. Elle vous dira peut-être que la nouvelle
|
||
fonctionnalité a un coût, mais aucune fonctionnalité ne doit être
|
||
impossible à implémenter parce qu'elle risque de casser l'existant.
|
||
|
||
|
||
Si quelque chose casse lorsque vous introduisez du changement, vous
|
||
perdrez beaucoup d'argent : il va falloir identifier (et ça peut être
|
||
très long!) et corriger ce qui a cassé, corriger la nouvelle
|
||
fonctionnalité, la tester, ajouter des ressources pour le support
|
||
applicatif...
|
||
|
||
|
||
Tous ces coûts, très importants sur le long terme, peuvent être réduits
|
||
en laissant à court terme une plus grande marge de manœuvre aux équipes
|
||
techniques pour fiabiliser leur code source et en écrivant des tests
|
||
automatisés. Ne soyez pas un mauvais économe : laissez leur le temps
|
||
qu'il faut pour vous fournir un produit plus stable et plus fiable. Vous
|
||
y gagnerez sur le long terme.
|
||
|
||
|
||
> Laissez le temps aux développeurs de fiabiliser leur code : aucune
|
||
fonctionnalité ne doit être impossible à implémenter sous prétexte
|
||
qu'elle risque de casser l'existant
|