Introducing TDD (Failure)
Introduction
Write down the reflections and results based on the case studies of automated testing. The benefits to cost and whether it is necessary in the first place are different stories.
| environment | Contents |
|---|---|
| OS | Linux |
| Development environment | Eclipse |
| Repository | GitLab |
| FW | SpringBoot |
| FW | Junit |
Introduced when building a new system
result
| Automatic test content | result |
|---|---|
| Implementation | 〇 |
| index | △ |
| Continue | × |
It wasn't maintained in about half a year, and it didn't last ... Man-hours are more than usual, I couldn't measure the introduction result, so I gradually handled it as luggage.
As a result of spending time implementing test indicators and common processing, the initial introduction was successful. ** It is a mistake to think that if the initial introduction goes well, the rest will start on its own. ** ** During the repair, there was a correction omission, it was postponed, and it became a subtle feeling.
Reflections and notices
I tend to focus on the test content, but ** I realize that the most important thing in the process of introducing TDD is not the contents but the mechanism ... **.
Also, I think this is a failure pattern that most people experience ** most. ** ** Indicators such as coverage and common processing are good, but they seem to be in time even after getting used to them. I will write an article about the result of thinking about the mechanism in "Success".
Introducing TDD (success) https://qiita.com/ilohas20983/items/365beea2756e00a7bfab