Introducing TDD (Failure) https://qiita.com/ilohas20983/items/b1ca1edbb2ad600a2b9c
I seriously thought about what it takes to get TDD familiar with the project.
First of all, the minimum requirement is to be able to see the man-hours in order to familiarize yourself. Otherwise no one will approve the work. ** A1. Standards and procedures ** are required to see the man-hours, If you try to adapt a new level of work that requires procedurality to your project, it will soon become obsolete. Then, ** A1. There is no choice but to automate **.
The immediate idea was to find out which test was in error.
In other words, ** A2. Automate test execution and automatically output test results **.
Test automation using gitlab-ci and automatic output of test results with the gradle plugin were immediately realized.
** I made it visible ** is not enough because I have to go to see it.
Make the pipeline result of gitlab-ci = automatic test result,
** A2. Made sure to be noticeable when approving merge request. ** **
First of all, I think that ** A3. Model Unit Test only ** using Mock etc. should be used. If Integration Test and E2e Test are also introduced together, there is a risk that the introduction effect will be measured and implemented apart from what they should be. If you focus on UnitTest, code coverage is enough for the index.
After preparing all the ** mechanisms ** described above, I used the ** contents ** created last time in combination. It has a good reputation, and after more than half a year, it hasn't run out of maintenance. I feel that it seems that the introduction of Integration Test and E2e Test will work. I think it would be nice to talk about what tools each is using and how.