Une heure passée à écrire un test est une heure non facturée, ou facturée à un client qui ne comprend pas toujours pourquoi. C’est la réalité budgétaire qui distingue un développeur freelance d’une équipe produit dotée d’un budget qualité dédié : il n’y a personne d’autre pour reprendre la suite de tests si elle prend du retard, et personne pour la maintenir pendant les congés.
Ce constat ne justifie pas de renoncer aux tests automatisés, mais il impose de choisir avec discernement où ils apportent le plus de valeur pour le temps investi. Ce billet ne traite ni le chiffrage client ni le choix des outils ; il propose des repères pour décider ce qui mérite un test automatisé et ce qui peut raisonnablement rester manuel.
Le critère qui compte : le coût d’une erreur silencieuse
La question à se poser n’est pas « puis-je tester ceci » mais « que se passe-t-il si cette fonction se trompe sans que personne ne le remarque immédiatement ». Un calcul de prix erroné dans un panier, une remise mal appliquée, un email de confirmation qui part au mauvais destinataire : ce sont des erreurs qui peuvent tourner plusieurs jours avant d’être repérées, et qui coûtent cher en réputation comme en remboursement.
- Fonctions de calcul (prix, remise, taxe, quota) : priorité haute, un test unitaire coûte peu et protège beaucoup.
- Traitements déclenchés automatiquement (cron, webhook entrant, synchronisation) : priorité haute, personne ne les observe en direct.
- Affichage visuel d’une page (mise en page, couleurs, espacement) : priorité basse, un œil humain détecte l’anomalie en quelques secondes.
Ce qui peut légitimement rester manuel
Tout ce qui se voit immédiatement à l’écran, et dont l’erreur ne coûte qu’un aller-retour rapide, ne justifie pas toujours l’investissement d’un test automatisé maintenu dans la durée. Une checklist de recette manuelle, suivie avant chaque mise en production, couvre ce terrain avec un effort de rédaction unique et un coût d’exécution faible :
Checklist de recette avant mise en production
- [ ] Le formulaire de contact envoie bien l'email de confirmation
- [ ] Le panier recalcule le total après ajout d'un article
- [ ] La page d'accueil s'affiche correctement sur mobile
- [ ] Les liens du pied de page ne renvoient pas d'erreur 404
Cette checklist ne remplace pas un test automatisé sur un calcul métier critique, mais elle couvre efficacement les régressions visuelles ou d’affichage, qui sont par nature immédiatement visibles par quiconque ouvre la page.
Un budget de temps réaliste, pas un idéal théorique
Viser une couverture large sur un projet facturé au forfait mène presque toujours à l’abandon : la suite de tests grossit plus vite que le temps disponible pour la maintenir, et elle finit par tourner en rouge sans que personne ne corrige, ce qui la rend pire qu’inexistante puisqu’elle inspire une fausse confiance.
Un repère plus tenable : consacrer un temps de test proportionnel au risque financier du module concerné, pas un pourcentage fixe du temps de développement. Une extension de calcul de commission mérite une demi-journée de tests unitaires ; un simple champ de formulaire supplémentaire n’en mérite aucun.
Choisir un petit noyau de tests qui survivra aux mois qui passent
Un freelance seul doit anticiper une réalité simple : dans six mois, il ne se souviendra plus des détails de cette extension. Les tests qui survivent sont ceux qui sont simples à comprendre au premier coup d’œil, sans dépendance complexe à maintenir :
- Un test par règle de calcul métier, avec un nom explicite sur le cas couvert.
- Un test par point d’intégration externe critique (paiement, envoi d’email), pour détecter une rupture de contrat côté service tiers.
- Aucun test sur l’affichage pur, sauf exigence contractuelle explicite du client.
Une suite de dix tests qui tournent tous et qu’on comprend en cinq minutes vaut mieux qu’une suite de cent tests dont la moitié est ignorée depuis des mois.
Documenter ce choix pour le client, sans jargon technique
Expliquer au client, en une phrase, ce qui est testé automatiquement et ce qui relève d’une vérification manuelle avant chaque mise à jour évite un malentendu fréquent : la croyance que « le développeur a testé » signifie que tout a été vérifié, y compris ce qui n’a jamais été couvert par aucun test ni aucune checklist.
En résumé
Seul face à un projet, le développeur freelance gagne à concentrer les tests automatisés sur ce qui coûte cher en cas d’erreur silencieuse, et à traiter le reste via une checklist de recette manuelle rejouée avant chaque mise en production. Ce compromis, moins ambitieux qu’une couverture large, a le mérite de tenir dans la durée sans jamais être abandonné faute de temps.
