Présentation de TDD (échec) https://qiita.com/ilohas20983/items/b1ca1edbb2ad600a2b9c
J'ai sérieusement réfléchi à ce qu'il fallait pour familiariser TDD avec le projet.
Tout d'abord, le minimum requis est de pouvoir voir le nombre d'étapes pour s'y habituer. Sinon, personne n'approuvera le travail. ** A1. Des normes et procédures ** sont nécessaires pour voir le nombre d'étapes, Si vous essayez d'adapter un nouveau niveau de travail qui nécessite de la procéduralité à votre projet, il sera ** bientôt obsolète **. Ensuite, ** A1. Il n'y a pas d'autre choix que d'automatiser **.
L'idée immédiate était de découvrir quel test était erroné.
En d'autres termes, ** A2. Automatisez l'exécution des tests et sortez automatiquement les résultats des tests **. L'automatisation des tests à l'aide de «gitlab-ci» et la sortie automatique des résultats des tests avec le plug-in «gradle» ont été immédiatement réalisées.
** Je l'ai rendu visible ** n'est pas suffisant car je dois aller le voir.
Faire le résultat du pipeline de gitlab-ci = résultat du test automatique
** A2. Assurez-vous d'être visible lors de l'approbation de la demande de fusion. ** **
Tout d'abord, je pense que ** A3. Model Unit Test uniquement ** utilisant Mock etc. Si le test d'intégration et le test E2e sont également introduits ensemble, il y a un risque que l'effet d'introduction soit mesuré et mis en œuvre indépendamment de ce qu'ils devraient être. Si vous vous concentrez sur UnitTest, la couverture de code est suffisante pour l'index.
Après avoir préparé tous les ** mécanismes ** décrits ci-dessus, j'ai utilisé le ** contenu ** créé la dernière fois en combinaison. Il a une bonne réputation, et après plus de six mois, il n'a pas manqué de maintenance. Je pense qu'il semble que l'introduction du test d'intégration et du test E2e fonctionnera. Je pense que ce serait bien de parler des outils que chacun utilise et comment.