이 포스트를 쓰게 된 계기는 TDD라는 허들을 어떻게 뛰어넘게 되었는지 설명하는 위해서입니다.
TDD는 한 번에 다루기 큰 주제이며 이 포스트에도 부족한 부분이 많을 것입니다. 가벼운 마음으로 읽어주면 좋을 것 같습니다.
저는 허들을 넘기 전 ”Test Code를 작성한다”라는 것에 대해 많은 어려움을 느꼈습니다.
가장 큰 이유는 명확히 어떤 것을 어떻게 Test Code로 작성 해야 하는지 몰랐기 때문입니다.
왜 어떤 것을 어떻게 Test Code로 작성 해야 하는지 몰랐을까?
- TDD를 어떻게 하는 지 몰랐다.
- 학습 비용이 있다. (JUnit, Spek, Mock, Rx … )
- Test Code를 작성했음에도 오히려 Test Hell이 됨
학습 비용을 제외한 다른 것들을 극복한 계기는 백명석님의 강의를 듣고 극복하게 되었습니다.
백명석님의 CleanCode강의는 40년 이상 개발자로 저명하신 Uncle Bob cleancode강의를 토대로 만드신 것 입니다.
켄트 백은 사람은 한 번에 두 가지 일을 하는 것이 어렵기 때문에 한 번에 한 가지만 집중하기 위하여 TDD 전략을 취한다고 설명합니다.
- RED 1단계 : “문제를 정의하는 것에 집중한다.”
- Green 2단계 : “그 문제를 해결하는데 집중한다.”
- Refactor 3단계 : “작성한 코드를 Clean Up하는 것에 집중한다.”
이 3단계 주기가 빈번하게 전환되어야 한다고 합니다.
Example 소인수 분해
이 포스트는 TDD의 허들을 뛰어넘기 위한 포스트로 자세한 문제를 풀이하는 과정은 여기서 확인할 수 있습니다.
소인수 분해란 합성수를 소수의 곱으로 나타내는 방법을 말합니다.
* 4=2×2
* 6=2×3
* 8=2×2×2
* 9=3×3
* 10=2×5
* 12=2×2×3
* 14=2×7
* 15=3×5
* 16=2×2×2×2
* 18=2×3×3
* 20=2×2×5
소인수 분해 문제 해결하는 과정을 0 -> 1 -> 2 -> N과 같이 점진적인 개선이 되는 것이 TDD의 가장 중요한 원칙입니다.
만약 최초부터 어려운 문제를 정의하고 해결한다면 그 이후로 나오는 문제를 해결 할 수 없는 상황이 발생할 수 있습니다.
이러한 상황은 ”Getting stuck”이라고 정의하며, 이 경우 두 가지 탈출 방법이 있습니다.
- 처음부터 다시 짠다.
- Production Code가 잘 동작하도록 수정한다.
가장 좋은 것은 Getting stuck의 상황이 발생하지 않도록 하는 것입니다.
마지막으로 무조건 TDD를 적용하기보다는 조직의 문화를 고려해야 하며,
유지보수를 하지 않는 코드는 TDD를 하지 않는 것이 좋습니다.
