[리팩토링] TDD 로 프로젝트의 전환의 타당성 분석

일단 프로젝트를 진행하면서 크게 느낀 사항이 있다.

• 소스를 먼저 짜놓고 테스트를 돌리는 경우

  사람의 마음이란게, 최대한 내 소스가 맞다고 생각하고 짜게된다.

  이건 테스트코드 뉴비의 경우 발생할 수 있는 문제라고 생각도 된다

• 개발자는 내가 작성한 코드에 대해 무의식적인 편향성 을 가지게 된다.

  내 코드는 내 머릿속에서 올바르게 돌아갈 수 밖에 없다 라는 가정 하에 테스트를 작성하게 되는데,

  이는 테스트가 진정한 오류 검출의 목적보다 내 코드에 대해

  테스트는 정확하게 다 통과하는데? 라는 사고로 코드를 정당화하는 도구로 변질시키게 된다.

• 실제로 테스트 코드의 에서
  • 장바구니 기능의 경우

    장바구니에서 테스크 코드안의 검증해야할 엣지케이스 가 있음직한 부분에서 실제 버그를 찾아내는 것보다

    코드가 통과할 수 있도록 테스트를 조정하는 데 더 많은 시간을 소비하게 되는 모습을 발견할 수 있었습니다.

---

• 회사의 프로젝트 같은 경우
  • 기획자가 별도 기획을 해서 로직의 플로우를 정해놓고 개발을 시작한다고 하더라도
  • 결국에는 중간의 개발상의 세부 로직이 변경되는 경우, 해당 내용을 개발하는 개발자도 변경사항에 대해 스스로 기록을 유실할 수 있다.
  • 또한 다른 개발자가 초기단계의 플로우로 이해하고 있더라도

    변경된 플로우의 케이스로 테스트코드를 보고 이해할 수 있을뿐더러

    변경된 플로우에 맞춰서 개발을 이어서 진행할 수 있는 이점을 누리게 된다.

고로 TDD 는

문서화의 역할을 수행할 수 있다.

• 변경 사항의 문서화 역할을 도입함으로

• 프로젝트 내에 커뮤니케이션 툴로서 작동이 가능하다

• 누구나 현재 코드가 어떤 요구사항을 만족해야하는지 쉽게 파악할 수 있다.

회귀 버그의 감소에 기여한다.

• 개발 중에 로직의 변경이 발생한다면, 그 변경이 다른 기능에 부정적인 영향을 미칠 수 있다

• TDD 를 통해 작성된 코드는 이러한 회귀 버그를 방지할 수 있다.

💡

회귀버그? 소프트웨어에서 이미 해결되었던 버그가 새로운 코드 변경으로 인해 다시 발생하는 현상

개발자에게 확신을 줄 수 있다.

• 솔직히 이 효과가 개발자가 체감할 수 있는 제일 큰 효과라고 생각한다.

• 테스트를 통과하는 것을 보면서 내가 처음에 의도했던 로직의 흐름인지 확인할 수 있습니다.

• 자신감 이 부족하면 로직에 불필요한 방어코드가 많이 들어가게 되며

  이후에 이러한 방어코드가 내 가슴에 비수로 날아오게 되는 경험을 너무 많이 겪었습니다..

Uploaded by N2T