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).
|
|||
|
|
|||
|
|
|||
|
![ Retrouvez toutes vos fonctionnalités au sein d'une même interface. ](behat-wizard-home.jpg)
|
|||
|
|
|||
|
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
|