L'objectif des tests est de s'assurer que le projet réponde au cahier des
charges et se comporte comme attendu.
Le premier test, c'est celui que nous faisons naturellement en écrivant un bout
de code, pour le lancer ensuite et vérifier s'il fait ce que nous souhaitons.
Ca a un côté grisant, car c'est interactif, le résultat est immédiat et la
correction s'en suit de suite.
Cependant, dans la pratique, ce n'est pas gérable sur le long-terme:
- oubli des situations intéressantes (il faut tester les cas aux limites !)
- cumul des combinatoires au fur-et-à-mesure de l'enrichissement des
fonctionnalités
- une fonctionnalité qui a marché à un moment peut ne plus fonctionner par
après
- des portions de code peuvent se trouver difficilement atteintes une fois que
le code s'est enrichi
- un projet conséquent ne pourra jamais être conçu d'une pièce avant d'être
exécuté !
La réponse est donc de mettre en place des tests automatisés, il existe des
études complètes sur ce thème et des outils spécialisés à ce sujet.
Ici, nous allons nous concentrer sur une approche en phase avec le
développement par "étapes successives qui marchent".
En effet, dans ce modèle, le projet est construit par palliers.
Chaque pallier est conçu de sorte qu'il fonctionne, même si seulement un
très petit sous-ensemble des fonctionnalités prévues est couvert.
Pour s'assurer que "l'étape marche" comme stipulé dans le pré-requis, il va
falloir le vérifier.
La méthodologie de test dans notre cas, sera de construire un test qui valide
que l'étape marche.
Là, où ça se corse un peu, c'est qu'il va falloir péréniser ce test,
c'est-à-dire que l'enjeu est qu'il puisse fonctionner plus tard, lorsque le
programme se sera enrichi des fonctionnalités futures.
C'est tout le travail de cette méthode.
La découpe en modules aide grandement à cela, il convient de structurer les
tests par modules et d'identifier comment solliciter chacun d'eux pour vérifier
leur comportement dans les cas de figure les plus essentiels, en particulier
les cas aux limites.
A côté de cela, au fur-et-à-mesure que l'application s'enrichit, une batterie
de tests permet de vérifier le fonctionnement de l'application dans son
ensemble.
Ainsi, les tests module par module, permette de valider les fonctionnalités des
modules individuels dans leur exhaustivité. Et les tests sur l'application
construite progressivement permet de valider le fonctionnement des modules
entre eux, dans les possibilités qui s'offrent à eux depuis les entrées système
et utilisateur. C'est-à-dire qu'un module fournira un éventail de sorties
limité par les entrées qui le sollicitent (qu'elles proviennent de
l'utilisateur ou du système), il ne sera donc pas forcément à même de stimuler
son voisin selon toutes ses entrées possibles.
La formalisation de ces tests dans un environnement de test donne une synthèse
de toutes les situations envisagées et des résultats obtenus.
Il permet leur exécution à guise et donc de vérifier à tout moment dans
l'évolution du projet que ce qui a marché à un moment donné marche
toujours. C'est ce qui s'appelle vérifier la non-régression.
Tout en conservant ce modèle, il sera bénéfique de s'appuyer sur des outils de
tests, qui nous facilitent la vie.
Je vous invite dès lors à lire la rubrique sur les moyens de tests pour Python
présentés dans cet article très riche:
https://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.