TestDeRecette

Un article de Agora2ia.

Une pratique XP très appréciée du client !


Les tests de recette, ou tests release ou encore tests d’acceptation, permettent de spécifier le système à priori, et de le valider à posteriori. Dit autrement, ils constituent une description détaillée sur ce qu’il faut faire et un retour d’information rapide sur ce qui est fait.


Ils sont idéalement écrits avec le client (en collaboration avec un binôme) mais assurément conçus par lui. Dans le cas idyllique où le client écrit les tests, il est à la charge de l’équipe de lui fournir un formalisme (« langage ») adapté.


Toujours idéalement ils seront écrits durant l’itération qui précèdent celle où la fonctionnalité doit être développée. Ainsi, au PlanningGame qui débutera l’itération des développements, le client comme le binôme ayant collaboré auront une idée précise de la fonctionnalité et de ses subtilités. L’explication par le client et la participation du binôme à l’estimation n’en seront que plus pertinentes.


Cette pratique des « tests release » à de réels impacts sur la ConceptionSimple de l’application, l’environnement de développement et le mode de fonctionnement de l’équipe : être capable de déployer à tout instant une version de chacun des deux parties cliente et serveur de l’application ainsi que de sa base de données n’est pas donné à toutes les équipes.


Ils doivent être automatisés afin de pouvoir être joués systématiquement en IntégrationContinue. Il faut bien comprendre que la motivation de cette pratique est de fournit un état d’avancement des fonctionnalités du systèmes, mais aussi de mettre en évidence les bugs éventuels voire des régressions. Plus tôt ces derniers sont détectés, plus facilement la cause sera identifiée, plus rapidement la correction sera apportée.


Paul et Mick dans l’extrême

Selon les interprétations, ces tests doivent se jouer rapidement (une dizaine de minutes) ou peuvent durer plus longtemps (de l’ordre d’une heure).


L’enjeu ici est que dans le premier cas ils pourront être joués intégralement et fréquemment, par exemple par tout binôme qui vient de finir une partie sensible de sa tâche. Mais pour pouvoir être rapides sur des projets complexes, les tests de recette devront bouchonner les parties limitantes, comme une base de données ou un serveur distant. Dans ce cas, on teste bien la fonctionnalité, mais dans un environnement cible qui n’est « que » simulé.