Recette & environnements de test

Par Martin

On a tous eu l’occasion de livrer une modification directement sur un serveur en production, pas grand chose souvent, et on a tous eu l’occasion de le regretter rapidement !

Heureusement, dans tout projet digne de ce nom, on met en place des procédures plus ou moins développées pour tester le code dans de bonnes conditions afin d’éviter les surprises et les régressions.

Toute un série de tests permettent de valider le côté qualitatif du projet. Ils sont rarement tous mis en œuvre, souvent partiellement, sauf sur des projets stratégiques, et bien souvent on prend juste l’essentiel. C’est souvent suffisant pour arriver à un résultat correct, même si il en faudrait parfois un peu plus…

Photo de Oncle Tom depuis Flickr

Que tester ?

L’idéal est de tout tester mais certains tests peuvent être décorrélés du reste. La configuration du serveur, les scripts de mise en production ou de maintenance ou encore le paramétrage des noms de domaines ne sont pas nécessaires à toutes les étapes du développement. On peut souvent les tester séparément du reste sans risques, jusqu’à l’assemblage final en pré-production. Sinon que ce soit des tests de bas niveau, dans le code ou fonctionnels, ils permettront de s’assurer que l’on répond le plus précisément au besoin exprimé.

De toutes façon, tout doit être testé, plus ou moins suivant les cas, on n’imagine pas laisser la moindre place au hasard dans ce processus..

Quels types de tests ?

A chaque étape du développement les tests doivent s’enchaîner, de plus en plus précis, pour arriver au final à une application avec un minimum failles.

Test unitaires

Ce sont parfois quasiment les seuls tests réalisés avant la recette. Ce sont les premiers effectués, directement par les développeurs. C’est évidemment une mauvaise pratique de laisser le soin au seul développeur de tester son code et le fonctionnel rapidement entre deux développements. Le test fait en ayant connaissance du code est toujours orienté, et si le fonctionnel était mal compris son application sera forcément à revoir…

Tant que ces tests ne sont pas automatisés ou au moins effectués par une tierce personne et suivis dans un cahier de tests ils sont quasiment inutiles car limités à des cas non exhaustifs et non reproductibles. La création d’un cahier des tests permet de limiter les effets négatifs, mais rend souvent le travail moins intéressant et parfois rébarbatif…

Et certains tests qui touchent à l’ergonomie ou aux bonnes pratiques ne peuvent être faits de manière automatique car ils requièrent une faculté d’analyse et un œil expert. Le recours à un spécialiste du sujet peut s’avérer décisif si le niveau de qualité à atteindre est conséquent.

Tests unitaires automatisés

Qu’ils soient côté serveur ou côté client, l’automatisation et la réutilisation sont leur point fort !

Côté serveur des frameworks comme JUnit ou PHPUnit permettent de tester de manière efficace les fonctions d’un projet. On teste avec différents paramètres en entrée et on vérifie la sortie sans oublier les cas devant générer des erreurs afin de vérifier que le comportement attendu est le bon.

Coté client des outils comme BadBoy ou Sélénium permettent d’enregistrer des macros et de les rejouer à volonté. On s’assure ainsi qu’il n’y a pas de régression fonctionnelles.

Ces tests automatisés peuvent être lancés après l’ajout d’une fonctionnalité ou la correction d’un bug de manière à éviter les régressions. On peut ainsi tester efficacement et complètement les différentes fonctionnalités développées. Ils peuvent aussi être utilisés de manière automatisée sur une plateforme d’intégration continue.

Avec cette méthode, on capitalise énormément, les tests sont rejouables à l’infini par le client qui peut s’assurer de la bonne conduite du projet et même par une équipe différente qui devrait reprendre le développement ou la maintenance.

Les test peuvent même être à l’origine des développements. En les écrivant avant, on s’assure de bien répondre à chaque cas. Le développement sera validé quand tous les tests passeront.

Quels environnements ?

Environnement de test local

Il évolue souvent en cours de route, suivant l’évolution du cahier des charges, des test des développeurs, des différents projet sur lesquels on peut être amené à travailler simultanément. Il n’est pas toujours évident de tout cloisonner et ce n’est pas forcément nécessaire. A ce stade il peut être intéressant pour les différents acteurs d’avoir une plateforme de travail sans liens communs. C’est particulièrement vrai chez un éditeur de logiciels, qui ne maîtrise pas forcément la plateforme cible de ces clients. Cela permet de capitaliser sur des expériences variées et de pouvoir répondre à un besoin différent facilement.

Pour avoir sous la main des environnements divers et variés pour tester différents clients web par exemple, le recours à des machines virtuelles ou « VM » est d’un grand secours. Vous pouvez ainsi avoir facilement sous la main plusieurs OS, et navigateurs dans des versions hétéroclites. Que ces VM soient sur votre poste ou en réseau, accessible à distance, elles vous permettront de faire vos tests dans d’excellentes conditions.

Environnement de recette

L’environnement de recette doit être proche de l’environnement final, au moment du développement il m’est arrivé assez souvent de ne pas connaitre précisément l’hébergement cible, on peut cependant partir sur les bases évidentes. Choix du langage, des version majeures des différents composants, paramétrages… Le but est d’être au plus près possible de la cible, de manière à ne pas avoir de mauvaises surprises par la suite. Évidemment plus tôt on aura une image précise du serveur de production, et mieux on pourra affiner cet environnement.

Environnement de pré-production

L’environnement de pré-production doit être une copie exacte de l’environnement de production, avec un paramétrage exactement similaire et des données de production. Et l’on ne peut transiger sur aucun de ces points ! Il faudra bien sûr veiller à répliquer et documenter immédiatement le moindre changement.

A chaque fois que l’on m’a imposé une différence si minime soit elle, une erreur est apparue en production. Le plus souvent très légère, c’est vrai mais quel intérêt de faire ce test si il n’est pas exhaustif

Conclusion

Les tests doivent être la base de tout développement, qu’ils soient faits de manière humaine ou automatisée, leur régularité permet d’anticiper les dérives et de corriger rapidement les erreurs.
Des contraintes temporelles ou budgétaires viennent souvent limiter leur mise en application, pensez alors à faire valider régulièrement l’avancée du projet par le client, à défaut de tests, c’est à lui de prendre ses responsabilités.

Sur le même thème

• Trouver un bon hebergeur web, quels critères ?
• Bien définir son projet de site web
• Optimiser son site web
• Fournir un webservice et son API
• Maquettage avec Pencil Sketching