Comment décidez-vous ce que vous couvrez par des tests unitaires plutôt que par des tests d'intégration ?

Testez unitairement la logique avec des branchements et des cas limites : règles de tarification, analyse syntaxique, machines à états. Testez en intégration les coutures où vos hypothèses rencontrent la réalité : requêtes en base, sérialisation, middleware d'authentification, clients tiers. Si un test a besoin de cinq mocks pour tourner, il teste surtout vos mocks et la valeur est plutôt dans un test d'intégration. Visez beaucoup de tests unitaires rapides plus un ensemble plus restreint de tests d'intégration couvrant les chemins critiques.

Je découpe selon l'endroit où vit le risque. Si le risque est logique, des branchements, des arrondis, des cas limites dans une machine à états, c'est un test unitaire, et il doit être assez rapide pour que je lance tout le fichier à chaque sauvegarde. Si le risque est à une couture, mon SQL renvoie-t-il vraiment ce que je crois, le JSON se sérialise-t-il comme le client l'attend, le middleware rejette-t-il un jeton expiré, c'est un test d'intégration avec une vraie base dans un conteneur. L'heuristique que j'utilise, c'est le nombre de mocks : s'il m'en faut quatre pour faire tourner un test, ce test affirme mon modèle mental de ces quatre choses, et mon modèle mental est exactement ce qui est faux quand ça casse en production. J'essaie aussi d'être honnête sur ce que je ne teste pas. Un contrôleur mince qui ne fait que passer les données, ou un accesseur, est couvert incidemment et le tester séparément est un coût de maintenance sans signal. La suite que je veux, c'est beaucoup de tests unitaires rapides et peut-être vingt tests d'intégration sur les chemins où il y a de l'argent ou de l'authentification.