/ TDD, ARCHITECTURE, CLEANCODERS, TDD

아키텍처와 클린코드 그리고 TDD (3)

TDD 원칙

  1. 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.
  2. 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.
  3. 현재 실패하고 있는 테스트를 성공하기에 충분한 정도를 넘어서는 프로덕션 코드를 작성하지 않는다.

Start -> write a failing test <-> write code to make it pass (refactoring) -> end

리팩터링은 옵션이 아니다!

원칙과 팁

  • 간단하고 쉬운것, 수준이하의 것부터.
    • 0 + 0… 0 + 1 …
  • 작은 골프게임.
    • 최소한의 코드로 돌아 갈 수 있게
  • 테스트가 더욱 구체화 될 수록, 프로덕션코드는 범용적이어야 한다.

TDD 잇점

  • Debugging Time 이 줄어든다.
    • 디버그 챔피언이 되고 싶은가? 그건 아니다. 하지만….
      • 이건 요구되는 스킬이 아니다.
      • 디버깅에 시간을 보내길 원치 않는다.
      • 코드가 동작하도록 하는데 시간을 사용하기 바란다.
    • TDD가 디버깅 시간을 1/10로 줄여 줄 것이다.
      • 그런데 1/10 이 아니라, 1/2만 줄여도 의미가 있다
  • 설계문서를 얻게 된다.
    • test is “Low level design document.”
  • Decoupling
    • 테스트를 먼저 작성하면 프로덕션 코드가 테스트 가능해진다.
    • 테스트 코드에서 코드라인을 접근하기 쉬운 유일한 방법은 Decouple 시키는 것이다.
  • Courage to change
    • 개발자가 코드를 깨끗하게 리팩토링 하는 것을 두려워하면 코드는 썩는다.
    • 테스트가 있어서 시스템이 정상 동작하는지 확인 할 수 있어서 두렵지 않을것이다.
      • 리그레이션(회귀) 테스트
      • 버그가 발견되면 버그를 재현하는 테스트를 추가한다. «< 중요한거 같음.
    • 완벽한 설계에 기반해 개발을 했더라도 테스트가 없다면, 코드를 클린하게 하는데 두려움이 생길것이다.
  • Trust
    • TAD(Test After Development)테스트를 신뢰할 수 없다. 항상 구멍이 있을것이라 생각할 것이다.
    • TAD는 지루하다. 이미 수작업으로 트스트 했기때문에 코드가 동작하는 것을 안다.

Search

Get more post