# Votre code doit refléter le Besoin fonctionnel

Vous le savez, il arrive très souvent qu'un besoin fonctionnel évolue au cours de 
la vie d'un projet. Et, parfois, une évolution fonctionnelle, même mineure, peut 
entraîner une refonte majeure d'un code source.

C'est l'effet boule de neige : modifier un bloc de code va avoir un impact sur une 
grande partie de code source, qui elle-même va concerner des domaines fonctionnels très variés, 
entraînant des régressions fonctionnelles nombreuses et imprévisibles.

Si vous l'avez vécu, vous savez que c'est quelque chose qui est totalement 
incompréhensible pour une personne qui n'est pas développeur. Ce n'est pas de la mauvaise 
volonté, non ; c'est simplement que, s'il est déjà difficile de saisir pleinement qu'écrire 
du code source permet au final d'avoir une application qui marche, comprendre qu'il existe 
dans le code source des interactions fines, complexes et non liées aux domaines fonctionnels est 
une chose quasiment impossible pour un fonctionnel.

Il faut donc trouver une solution pour répondre à ces deux questions fondamentales :

+ comment assurer la cohérence des changements techniques face aux changements fonctionnels ?
+ comment permettre aux fonctionnels d'anticiper le coût technique d'un changement fonctionnel ?

## Le Domain Driven Design

C'est justement l'enjeu du Domain Driven Design de répondre à ces questions. L'objet de 
cet ouvrage n'est pas de faire de vous des spécialistes du Domain Driven Design (ou DDD) en 
quelques pages. Non, il existe des livres très bien conçus, que je ne peux que vous inviter à 
lire *(cf. Domain Driven Design Vite Fait + DDD de Eric Envans) - Liens à mettre*

Non, l'objectif ici est de comprendre qu'il existe des démarches de travail et de conception 
logicielle qui permettent de faciliter la gestion du besoin fonctionnel. Et c'est là, justement, l'objet du DDD.

Le DDD est une démarche d'échange, de conception et de développement, dont l'objectif est de calquer 
le code source (code, base de données, ressources...) sur le besoin métier.

Impossible ? Si, et même très profitable. Sitôt que vous aurez commencé à travailler de cette manière, 
vous ne pourrez plus vous en passer.

L'idée générale est d'élaborer une Langue commune (cette Langue dont nous avons déjà parlé) avec 
le fonctionnel, puis de concevoir une cartographie fonctionnelle de l'application, afin 
d'utiliser, dans le code source, uniquement des concepts présents dans le domaine fonctionnel.

Dès lors, si cette démarche a été accomplie, il devient facile pour le développeur 
d'identifier quelle proportion de code et quels modules techniques seront impactés par une 
demande de changement fonctionnel : il lui "suffit" de superposer le nouveau besoin fonctionnel 
sur l'ancien code source.

De cette manière, toute modification technique devient représentative des modifications fonctionnelles : 
une modification fonctionnelle mineure risque moins d'entraîner une refonte technique longue et coûteuse. 
Et a contrario, il est totalement légitime qu'une évolution fonctionnelle lourde nécessite une refonte 
tout autant importante du code source.

De manière générale, il est important de prendre conscience que le travail du développeur est de répondre à 
un besoin fonctionnel. Il est donc important de structurer son code, de quelque manière que ce soit, de 
façon à répondre au mieux et le plus facilement à ce besoin.

> Les impacts techniques doivent être à la mesure des changements fonctionnels

## Les tests unitaires sont indispensables

En informatique on adore les sigles ; connaissez-vous le VDD ? C'est un sigle à la mode qui désigne
le "var_dump driven development", ou autrement dit, le développement piloté par la fonction `var_dump()` de PHP. 
Notez que ça marche aussi si vous faites un `console.log()` en JavaScript, ou dans n'importe quel langage...

Pourquoi est-ce une expression à la mode ? Tout simplement parce qu'elle désigne une pratique de développement 
vouée à l'extinction, qui consiste pour le développeur à afficher à l'écran les valeurs de certaines variables pour 
en vérifier le contenu manuellement. 

La raison pour laquelle cette pratique est vouée à disparaître est simple : lorsque l'on vérifie à la main 
une valeur d'une variable, c'est long, ennuyant, et on risque de faire des erreurs. 

En réalité, faire un var_dump() pour afficher une information à l'écran n'est ni plus ni moins qu'un contrôle sur 
l'état d'une variable. Or il est très facile d'imaginer des robots dont la seule fonction est de s'assurer en permanence 
de l'état d'une variable. Et ces robots, infatigables et extrêmement rapides, ne se tromperont jamais.

Ces robots, ce sont les tests unitaires automatisés. Écrire des tests unitaires est, à ce jour, l'un des seuls moyens vraiment efficaces 
pour faciliter la vie d'un développeur, fiabiliser son code et réduire les coûts de maintenance d'une application.

Il existe dans tous les langages de programmation des outils qui facilitent la rédaction de tests unitaires : JUnit en Java, QUnit en JavaScript...
En PHP, deux outils se démarquent par leur fiabilité et leur grande communauté: [PHPUnit](http://phpunit.de), développé par Sebastian Bergmann, 
et [atoum](http://docs.atoum.org), développé par Frédéric Hardy. Ces deux outils proposent une approche légèrement différente des tests unitaires, 
mais sont tous les deux simples, efficaces et complets.

De manière générale, rédiger un test unitaire consiste à dérouler un processus simple :

+ mettre en condition un code que l'on souhaite tester : ce sont les conditions du test
+ exécuter une commande : il s'agit de ce que l'on souhaite tester
+ décrire quel doit être l'effet de la commande : il s'agit alors du résultat attendu

Lorsque l'on affiche une variable à l'écran pour vérifier sa valeur, en réalité, tout ce que l'on fait c'est exiger que 
cette variable ait telle ou telle valeur. En d'autres termes, *on fait une assertion sur la valeur de la variable*. 
Et toute assertion peut être traduite en code source.

On peut imaginer, par exemple, créer un test unitaire automatisé pour une fonction d'addition, qui utiliserait la 
fonction PHP native `assert()` :

    [php]
    $resultat = addition(5,5);
    assert($resultat === 10);

Ce code PHP générera une erreur si la fonction addition() ne renvoie pas "10".

L'avantage d'utiliser un outil de tests automatisés sera de pouvoir organiser ses tests facilement et efficacement. Chaque 
assertion valide sera affichée en vert, les erreurs seront remontées aux développeur en un instant. 


![ Les tests unitaires permettent de s'assurent que le code fonctionne comme prévu](phpunit.png)

Grâce aux tests automatisés, vous saurez à tout instant si vous venez de tout casser ou pas ; 
ce sera d'autant plus facile de tout réparer...

> Les tests unitaires sont le seul moyen efficace de fiabiliser un code source

## Tester le besoin métier est indispensable

Tester son code source est bien. C'est même déjà pas mal du tout ! Mais une application web est plus qu'un code source : c'est 
un assemblage de *comportements* (code source) *vis-à-vis d'informations* (données, souvent issues d'une base de données), *pour 
délivrer un message* (par exemple une page web), le tout exécuté dans un environnement spécifique (serveur), le tout 
*vis-à-vis d'un utilisateur* (navigateur).

On comprend vite du coup que ce n'est pas parce qu'un code source fonctionne de la manière attendue que l'application, elle aussi, 
aura le comportement désiré.

Bien plus, il est en réalité difficile de tester unitairement l'ensemble d'un code source : c'est long et coûteux, et cela 
exige des changements importants dans les pratiques de développement (Développement piloté par les tests, génération de 
tests aléatoires, etc.).

C'est pour ces raisons qu'il existe différents niveaux de tests automatisés : 

+ les *tests d'intégration*, qui s'assurent de l'environnement donné (version de PHP, présence d'un module apache...)
+ les *tests de charge*, qui s'assurent de la performance d'une application
+ les *tests unitaires*, qui vérifient le comportement du code source
+ les *tests d'interface*, qui vérifient qu'une application a bien l'aspect attendu
+ les *tests fonctionnels*, qui s'assurent que l'application délivre bien un service métier à l'utilisateur

Il existe bien entendu d'autres niveaux de tests (sécurité, cohérence...), mais ceux-ci sont les plus 
répandus.

Le dernier niveau de test (le test fonctionnel) est sans doute parmi les plus importants. Finalement, tout votre travail 
consiste justement à faire en sorte que l'utilisateur tire un bénéfice fonctionnel d'une application. S'assurer que 
ce bénéfice fonctionnel est bien présent est indispensable pour votre client.

Mais justement, ce contrôle, autrement dit ce travail de Recette client, est long et laborieux. Il est source 
d'erreurs, et surtout il est impossible de contrôler à la main, lors de chaque évolution fonctionnelle, que 
l'ensemble de l'application fonctionne toujours de la manière attendue.

C'est pour cela qu'il existe désormais des outils de tests fonctionnels automatisés. Ces outils sont 
infatigables: ils traquent en permanence votre application à la recherche d'anomalies fonctionnelles.

Nous verrons par la suite comment mettre en place ces outils. Mais avant de faire une recette fonctionnelle, 
il faut déjà commencer par comprendre la demande initiale. Il est temps de découvrir comment faciliter la compréhension 
d'une demande fonctionnelle.
