Il faut trouver un juste milieu, ça dépend des types de logiciels je pense.
Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur.
Le choix du niveau du test (bas ou haut niveau) peut aussi se faire en fonction de la complexité de mise en oeuvre du test. C'est parfois bien plus facile de stimuler (ou simuler) une erreur bas niveau en unitaire, plutôt qu'en test de haut niveau ou test sur environnement intégré (par exemple, des cas de race condition).
Sur le projet sur lequel je travaille (un système distribué), on a trois niveaux de tests :
- test unitaire bas niveau : on test les rouages, les algos, les traitements des données, ...
- test de pré-intégration : on test le comportement du composant logiciel, s'il répond bien aux entrées, sans forcément regarder dans le détail les données qui sortent. C'est un test de plus haut niveau déjà.
- test de validation : tous les composants sont intégrés, on test alors qu'ils communiquent bien ensemble (interfaces), ainsi que les cas nominaux en partant du bas de la chaîne jusqu'au résultat final. Les cas d'erreurs peuvent par contre être extrêmement chers à mettre en place.
On a bien sûr pas la même couverture sur chacun de ces niveaux de tests.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Meku (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
Il faut trouver un juste milieu, ça dépend des types de logiciels je pense.
Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur.
Le choix du niveau du test (bas ou haut niveau) peut aussi se faire en fonction de la complexité de mise en oeuvre du test. C'est parfois bien plus facile de stimuler (ou simuler) une erreur bas niveau en unitaire, plutôt qu'en test de haut niveau ou test sur environnement intégré (par exemple, des cas de race condition).
Sur le projet sur lequel je travaille (un système distribué), on a trois niveaux de tests :
- test unitaire bas niveau : on test les rouages, les algos, les traitements des données, ...
- test de pré-intégration : on test le comportement du composant logiciel, s'il répond bien aux entrées, sans forcément regarder dans le détail les données qui sortent. C'est un test de plus haut niveau déjà.
- test de validation : tous les composants sont intégrés, on test alors qu'ils communiquent bien ensemble (interfaces), ainsi que les cas nominaux en partant du bas de la chaîne jusqu'au résultat final. Les cas d'erreurs peuvent par contre être extrêmement chers à mettre en place.
On a bien sûr pas la même couverture sur chacun de ces niveaux de tests.