Le test écrit par l'outil qui a écrit le code
Demander à l'outil de générer les tests du code qu'il vient de suggérer produit quelque chose d'utile et de trompeur.
Utile : la structure est là, les cas nominaux sont couverts, l'effort de démarrage disparaît.
Trompeur : ces tests décrivent ce que le code fait, pas ce qu'il devrait faire. Si la suggestion a mal interprété le besoin, le test valide l'erreur, et la couverture affiche du vert sur un comportement faux.
La règle qui en découle : les cas de test se décident avant, par vous. L'outil peut ensuite les écrire.
Ce qui doit venir de vous
Trois choses, et elles ne sont pas dans le code.
La liste des cas à couvrir, y compris ceux qui n'apparaissent pas dans l'implémentation actuelle. Un cas absent du code est absent des tests générés, et c'est souvent le cas manquant qui produira la panne.
Les valeurs limites réelles de votre métier. Un montant négatif, une date antérieure à la création du compte, un identifiant d'un client supprimé. L'outil ne connaît pas vos règles.
Le comportement attendu en cas d'erreur. Faut-il lever une exception, renvoyer une valeur par défaut, journaliser ? C'est une décision de conception, pas une propriété du code.
Une méthode qui marche
Écrivez d'abord les noms des tests, en français ou en anglais, sous forme d'affirmations :
refuse un montant negatif
accepte un montant a zero
arrondit au centime superieur
leve une erreur si le client est archive
Puis demandez à l'outil de les implémenter. Vous gardez la décision, il fait la saisie. C'est la répartition la plus saine que j'aie vue sur ce sujet.
La revue par un humain
Quand une part croissante du code est suggérée, la revue change de nature. Elle porte moins sur le style, que les outils gèrent, et davantage sur trois questions.
Est-ce le bon problème ? Le code peut être excellent et résoudre autre chose que ce qui était demandé.
Y a-t-il du code inutile ? Les suggestions ajoutent volontiers de la gestion de cas qui n'arrivent jamais, des paramètres non utilisés, des abstractions prématurées. C'est du code à maintenir pour rien.
L'auteur comprend-il ce qu'il propose ? Question désagréable et nécessaire. Un code accepté sans être compris n'a pas de propriétaire.
Le signal qui doit alerter
Une demande de fusion dont l'auteur ne peut pas expliquer une ligne. Ce n'est pas un procès : c'est le meilleur indicateur qu'une relecture est nécessaire, et l'occasion de rappeler que la responsabilité du code reste celle de qui le soumet.
À retenir
Décidez les cas de test avant, laissez l'outil les écrire. Un test généré depuis le code valide le code, y compris s'il est faux. La revue porte sur le bon problème, le code inutile et la compréhension de l'auteur, pas sur le style.