N'oubliez pas les tests dans vos projets !

Les tests sont au cœur des projets informatiques. Tous les chefs de projets sont unanimes sur ce point. Mais lorsqu’un projet accumule du retard, comme bien souvent, les tests seront dé-priorisés… On se promet d’écrire les tests lorsqu’on aura du temps… vraiment ? En effet les tests n’ont pas d’impacts directs ou visuels pour les utilisateurs. Les clients demandent des améliorations concrètes : nouvelles fonctionnalités, correction de bugs, meilleures performances… C’est plus difficile d’expliquer qu’une partie du budget va être consacrée aux tests. Une perte de temps et d’argent ?

Types de tests

On identifie classiquement plusieurs catégories de tests :

  • Les tests unitaires regroupent l’ensemble des tests bas-niveau d’une application. Ce sont des tests courts, indépendants, rapides, qui ne dépendent pas de services externes.
  • Les tests d’intégration permettent de tester les fonctionnalités d’une application en faisant appel à différents services si besoin.
  • Les tests système regroupent une ensemble de tests assez vastes, comme les tests de performances.
  • Les tests d’acceptation, aussi appelés “la recette”, pour vérifier que les spécifications attendues ont bien été implémentées.

Les tests sont pénibles à écrire

Écrire des scénarios de tests est en effet assez répétitif et peu stimulant.

Il existe un bon nombre de librairies et outils pour faciliter la création de tests unitaires :

Pour les tests dépendants de services externes comme des bases de données, il est possible d’utiliser des mocks (comme avec Mockito pour Java) ou des containers Docker. Regarder le projet Open Source Testcontainers qui simplifie la gestion du cycle de vie des containers dans les tests.

Pour les tests d’interface web la solution Selenium fait figure de référence, même si de nouveaux acteurs comme Cypress ont émergé récemment.

Impliquer les équipes non-techniques

Il est important d’embarquer les personnes clefs dans les scénarios de test. C’est le principe du Behavior-driven development (BDD)

L’environnent de tests est différent de l’environnent de production

Reproduire un environnement de tests proches des conditions de production n’est pas facile à réaliser.

Importer des données pour les tests

Il faut lancer des tests en utilisant des données “en condition réelle” pour reproduire assez fidèlement le comportement réel de l’application.

Les développeurs font généralement une copie partielle des données de production vers l’environnement de test. Il faut cependant respecter la confidentialité des données en anonymisant ou masquant certaines données (Data masking).

Les tests ne sont pas une “perte de temps” mais un contrôle de qualité et un gain de temps à long terme.

Difficulté des tests

Les scénarios de tests sont, hélas, souvent délaissés voire ignorés dans les projets informatique. Les justifications ne manquent pas : par manque de temps, manque d’intérêt ...

Les tests ont cet aspect particulier dans un projet. Les tests n’ont pas d’impacts visibles auprès des utilisateurs.

Les raisons sont nombreuses

“Désolé, on a pas eu le temps d’écrire les tests, on nous a demandé de développer une nouvelle fonctionnalité”

Les tests sont souvent le parent pauvre dans les projets informatiques.

Les tests sont souvent délaissés et la tentation de les négliger est grande

Les tests sont au cœur d’un projet

Il est important de se pencher sur les tests durant les différentes phases d’un projet.

Tester en continu

Il est important de tester durant toutes les phases de vie du projet

  • Lors de la mise en place d’une nouvelle fonctionnalité, les tests assurent que les spécifications sont respectées.
  • Lors de la découverte d’un bug, il est important de reproduire le bug par un test, puis de vérifier que le correctif modifie le résultat du test.
  • Lors d’une migration (d’une base de donnée par exemple), les tests permettent de s’assurer du comportant de l’application avant et après la migration.

Que tester ?

Il est impossible de tester toutes les fonctionnalités de l’application. On veillera dans un premier temps à tester les fonctionnalités critiques ou très utilisés de l’application.

Il est aussi intéressant de réaliser des tests de résistance ou stress testing pour vérifier le comportement d’une application dans un état inhabituel. Voici quelques exemples : des données vides, des chaines de caractères dans une langue étrangère, fichiers mal encodés, dates de naissance dans le futur, des taux/prix négatifs…

Développement piloté par les tests

La méthode Test-Driven Development (TDD) incite à écrire les tests avant d’écrire le code technique.

Références