Einführung von TDD (Fehler) https://qiita.com/ilohas20983/items/b1ca1edbb2ad600a2b9c
Ich habe ernsthaft darüber nachgedacht, was nötig ist, um TDD mit dem Projekt vertraut zu machen.
Zuallererst ist es die Mindestanforderung, die Anzahl der Schritte sehen zu können, um sich daran zu gewöhnen. Andernfalls wird niemand die Arbeit genehmigen. ** A1. Standards und Verfahren ** sind erforderlich, um die Anzahl der Schritte zu sehen. Wenn Sie versuchen, eine neue Arbeitsebene anzupassen, die Prozeduralität für Ihr Projekt erfordert, wird sie bald veraltet sein. Dann ** A1. Es bleibt keine andere Wahl, als zu automatisieren **.
Die unmittelbare Idee war herauszufinden, welcher Test fehlerhaft war.
Mit anderen Worten, ** A2. Automatisieren Sie die Testausführung und geben Sie die Testergebnisse automatisch aus **. Die Testautomatisierung mit "gitlab-ci" und die automatische Ausgabe der Testergebnisse mit dem "gradle" -Plug-In wurden sofort realisiert.
** Ich habe es sichtbar gemacht ** ist nicht genug, weil ich gehen muss, um es zu sehen.
Machen Sie das Pipeline-Ergebnis von gitlab-ci = automatisches Testergebnis
** A2. Achten Sie darauf, dass Sie beim Genehmigen der Zusammenführungsanforderung auffallen. ** ** **
Zunächst denke ich, dass ** A3. Model Unit Test ** nur mit Mock usw. verwendet werden sollte. Wenn Integrationstest und E2e-Test auch zusammen eingeführt werden, besteht das Risiko, dass der Einführungseffekt gemessen und implementiert wird, unabhängig davon, was er sein sollte. Wenn Sie sich auf UnitTest konzentrieren, reicht die Codeabdeckung für den Index aus.
Nachdem ich alle oben beschriebenen ** Mechanismen ** vorbereitet hatte, habe ich die zuletzt erstellten ** Inhalte ** in Kombination verwendet. Es hat einen guten Ruf und nach mehr als einem halben Jahr ist die Wartung nicht erschöpft. Ich denke, dass die Einführung von Integration Test und E2e Test anscheinend funktionieren wird. Ich denke, es wäre schön, darüber zu sprechen, welche Tools jeder verwendet und wie.