아키텍처와 클린코드 그리고 TDD (3)
TDD 원칙
- 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.
- 실패하는 테스트 코드를 한 번에 하나 이상 작성하지 않는다.
- 현재 실패하고 있는 테스트를 성공하기에 충분한 정도를 넘어서는 프로덕션 코드를 작성하지 않는다.
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