Stratégie de testAuteur : Julien Gauchet le 05/07/2017 (1 revision)

Se doter d'une stratégie de test cohérente est réfléchie est indispensable. Chaque projet peut avoir une stratégie différente dans la mesure où celle-ci a été réfléchie en fonction des attentes et des besoins en matière de test unitaire.

1. Choisir les éléments à tester

Lorsqu'on gère une application, nous pouvons être confrontés à plusieurs problèmes avec nos tests unitaires :

  • Les tests unitaires n'existent pas : le problème le plus fréquent
  • Les tests unitaires échouent tous systématiquement : ce qui est équivalent au premier point
  • Les tests unitaires sont compliqués à maintenir : une évolution mineure du programme entraine une évolution majeure des tests unitaires
  • Les tests unitaires ne couvrent que très mal les fonctionnalités de l'application et le fait que les tests unitaires fonctionnent ne nous assure pas que le programme ne contient pas d'erreurs majeures

Comment donc se prémunir de ces problèmes lors du développement d'une application ? Voici quelques pistes qui peuvent vous aider à définir votre stratégie de test, d'autres solutions existent il s'agit d'une méthode personnelle :

1.1. Réaliser des tests simples

La maintenance du jeu de test sera couteuse, il convient donc de ne pas être trop ambitieux sur les tests, et de ne pas valider l'ensemble des résultats d'un traitement mais de ce concentrer sur l'essentiel

Par exemple, pour tester une requête qui insère 10 lignes dans une base de données, nous pouvons tester :

  • Que 10 lignes ont été insérées
  • Que les données de la première ligne sont correctes

Plutot que de tester le contenu du toutes les lignes ce test unitaire sera plus simple à maintenir et plus simple à écrire sans pour autant présenter plus de risques que le test complet

1.2. Se concentrer sur le scénario nominal

Un indicateur important pour les tests unitaires est la couverture de test : le nombre de lignes de code par lesquelles on passe pour effectuer un test. Cet indicateur peut nous pousser à écrire des tests unitaires balayant tous les cas possibles sans tenir compte des cas vraissemblables

Cette stratégie est une erreur : nous passerons beaucoup de temps à écrire des jeux de test pour valider des comportements qui n'arriveront jamais alors que les cas concrets seront sous représentés

Ainsi, il convient de ne tester les méthodes qu'avec des arguments vraissemblables : ne pas tester systématiquement les méthodes avec des paramètres null par exemple si ceci n'a pas de sens fonctionnel.

De cette manière, le jeu de test sera plus facile à maintenir et aura plus de chances d'identifier un bug important : si un bug à 1 chance sur 1000 de se produire et que sa gravité est minime alors le test unitaire ne sert à rien sur ce cas.

1.3. Penser à l'évolution des tests

Les tests doivent évoluer au même rythme que le code, il faut toujours écrire les tests unitaires dans l'objectif qu'ils soient toujours utilisés dans 10 ans. Ainsi il convient de mettre en place des méthodes permettant de nous assurer que le test fonctionnera encore dans plusieurs années

L'erreur que je vais décrire est très primaire mais néamoins fréquente : nous avons une classe GestionCalendrier qui permet de récupérer l'année courante, la méthode permettant de récupérer l'année fait appel à la date système

Nous mettons en place le test suivant :

@Test
public void testerGetAnnneCourante(){
	Assert.assertEquals(2017, GestionCalendrier.getAnneeCourante());
}

Dès l'an prochain, le code ne fonctionnera plus. Cette erreur peut également se cacher dans des requêtes sql faisant appel à CURENT_TIMESTAMP

1.4. Ne pas se baser sur un environnement extérieur aux programmes

Tôt ou tard, si nous utilisons des resources externes (bases de données) et que nous considérons que nous allons trouver la base dans un état donné, nous perdrons nos tests unitaires parce que la base ne sera plus à jour.

Pour éviter de perdre nos tests, il est important de réinitialiser les données de la base de données avant chaque test : nous ne savons pas a priori ce que la base contient

2. Utiliser une conception adaptée

Nous l'avons vu au cours de cette formation, tester proprement un programme demande une conception adaptée. Le pattern MVC est d'une grande aide afin d'obtenir une application testable

3. Tester dès le début

Parce que nous allons adapter la conception de l'application pour rendre les tests possibles, il est important de commencer les tests unitaires dès le début du projet. Sans quoi la mise en place des tests unitaires sera couteuse : il faudra adapter la conception de toute l'application