TDD

원칙 & 팁

• 간단한 것 부터 짠다 / 가장 만만하고 쉽고 흥미로워 보이는 부분 부터 한다.
• little golf game
  • fail 하는 테스트 작성 후, production 코드를 작성할 때, 아주 적은 코딩 만으로 돌아갈 수 있도록 한다
  • 너무 고민하면서 작성하지 않는다.
• As the tests get more specific, the code gets more generic

TDD의 잇점

• Debugging TIme을 줄일 수 있다.
  • 디버깅에 시간을 들이길 보다 동작하는 코드를 작성하는데 시간을 쓰는 것이 요구된다.
• Design Documents
  • TDD의 3가지 법칙을 잘 따르면 설계 문서를 얻게 된다.
• Decoupling
  • TDD로 구현하면 보다 decouple된 시스템을 갖게 된다.
  • 테스트를 먼저 작성하면, 테스트 하기 어려운 코드를 만들 수가 없다.
• Courage to Change
  • 테스트가 있어서 시스템이 정상적으로 동작하는지 확인할 수 있다면 변경이 두렵지 않을 것
  • 만약 버그가 나왔을 때, 해당 버그를 잡을 수 있는 테스트를 작성 후, 버그 고치는 코드를 작성한다.
  • 완벽한 설계에 기반해 개발을 했더라도 테스트가 없다면 코드를 clean하는데 두려움이 생길 것이다.
• Trust
  • 3가지 규칙을 준수했을 때 낙하산에 대한 것과 같은 믿음을 테스트에 가질 수 있게 된다.
  • TAD(Test After Development)
    • 테스트를 신뢰할 수 없다.
    • 낭비적으로 느껴진다.
    • 항상 구멍이 있을 것이라 생각할 것이다.

Movie rate에 대한 TDD 예제 작성

Reference

백명석의 클린코드 - 유투브 영상