Quelle différence entre tests fonctionnels et tests unitaires ?

Deux échelles d'observation

Un test unitaire regarde une seule fonction, isolée du reste : le calcul d'une TVA, le formatage d'une date, le comportement attendu quand on lui passe une valeur vide. Il s'exécute en quelques millisecondes et il en existe souvent des centaines.

Un test fonctionnel regarde un parcours entier, tel qu'une personne le vit : arriver sur le site, créer un compte, ajouter au panier, payer, recevoir la confirmation. Il pilote un vrai navigateur, il est bien plus lent, et il en existe rarement plus de quelques dizaines.

Ce que chacun vous dit quand il échoue

• Test unitaire en échec : vous savez immédiatement quelle fonction est cassée et par quel changement. Le diagnostic est immédiat, la portée est étroite.
• Test fonctionnel en échec : vous savez qu'un client ne peut plus commander. La cause demande une investigation, mais l'information est celle qui compte pour l'entreprise.

C'est pour cela qu'ils ne se remplacent pas. Une base entièrement couverte de tests unitaires peut laisser passer une commande impossible à finaliser parce que deux composants corrects ne s'assemblent pas.

Par où commencer quand il n'y a rien

L'ordre qui donne le plus de valeur au plus vite est contre-intuitif : commencer par quelques tests fonctionnels sur les parcours qui rapportent de l'argent, même s'ils sont lents et imparfaits. Ils protègent immédiatement contre les pannes qui se voient.

Les tests unitaires viennent ensuite, en priorité sur les règles métier complexes et sur tout ce qui a déjà causé un incident. Chercher un taux de couverture élevé dès le départ produit surtout beaucoup de tests sans intérêt sur du code trivial.