À quoi ressemble votre stratégie de test sur une application full stack ?

Pondérez par le risque plutôt que par le dogme de la pyramide. Des tests unitaires pour la logique pure et les cas limites, une bonne couche de tests d'intégration qui tapent une vraie base dans un conteneur, et un petit nombre de tests de bout en bout couvrant les parcours qui font perdre de l'argent s'ils cassent, comme l'inscription, le paiement et le login. Mockez les tiers à la frontière réseau plutôt que de stubber vos propres modules.

Ma règle directrice, c'est qu'un test vaut la peine d'être écrit s'il aurait attrapé un bug qu'on aurait plausiblement livré. La logique pure, les règles de tarification, la gestion des dates, les contrôles de permissions, reçoivent des tests unitaires rapides avec les cas limites tordus. La couche dans laquelle j'investis le plus, c'est l'intégration : vraie requête HTTP dans l'application, vrai Postgres dans un conteneur, vraies migrations, assertion sur la réponse et sur les lignes qui en résultent. Ça attrape ce que les mocks cachent, comme une violation de contrainte ou une requête qui ne renvoie silencieusement rien. Les tiers sont mockés à la frontière réseau avec quelque chose comme MSW ou une fixture enregistrée, jamais en stubbant ma propre classe de service, parce que sinon je teste le mock. Le bout en bout, je le garde délibérément petit, peut-être huit parcours couvrant inscription, login, paiement et le flux principal, exécutés à chaque merge. L'instabilité, c'est le point sur lequel je suis impitoyable ; un test qui échoue au hasard apprend aux gens à relancer le pipeline, donc je le répare ou je le supprime dans la journée. La couverture, je la regarde comme un diagnostic, jamais comme un objectif.