TDD란?

클린코더스 - 백명석님 강의를 보고 작성한 글입니다.

1. TDD의 세가지 법칙

• Failing Test가 있을때만 프로덕션코드에 작성하라
• 실패를 나타내는데 충분한 테스트만 작성하라.
• 테스트가 성공하는 만큼만의 코드를 작성하라. (이해가 아직 잘 안됨..)

2. TDD 절차

세가지 법칙이나 TDD작성 절차를 지키지 않았을경우 Stocking이라는 옴짝달싹하지 못하는 상태에 빠질 수 있다.

1. Failing 테스트 작성(Red page)
2. Failing 테스트를 통과할 만큼의 코드를 작성(Green page)
3. Refactor(Blue Page)

   리팩토링 전까지 모두 최소한의 코드를 작성해서 절차를 만족시키기만 하면된다. 일단 돌아만 가게하면된다. Refactor는 선택이 아닌 필수이다.

3. 원칙

• 남들이 봤을때 별거 아닌 것처럼 보일만큼 쉬운 것부터!!
• 테스트가 구체적으로 변해갈 때 프로덕션 코드는 점점 범용(Generic)적이 되어간다.

4. TDD의 이점

Debugging Time

• TDD가 디버깅시간을 1/10으로 줄여 줄 것이다.

Design Documents

• TDD의 3가지 법칙을 잘 따르면 설계문서를 얻을 수 있다.(low level design Document이다.)

Decoupling

• 테스트를 먼저 작성하면 Prooduction 코드가 테스트 가능해진다.
• 모든 코드라인을 테스트하는 유일한 방법은 테스트 코드에서 그 코드들에 접근하는 것이다.
• TDD로 구현하면 보다 decouple된 시스템을 갖게된다.

Courage to Change

• 테스트가 있기 때문에 시스템이 정상적으로 동작하는지 확인할 수 있다면 변경이 두렵지 않다. => Refactor를 공격적으로 할 수 있다.
• 테스트는 코드를 깨끗하게 하고, 썩는 것을 방지한다.
• 하지만, 레거시한 코드에 테스트를 추가하기는 힘들다.
• regression test
• 완벽한 설계에 기반해 개발을 했더라도 테스트가 없다면 코드를 clean하는데 두려움이 생길 것이다.

Trust

• 3가지 규칙을 준수했을 때 낙하산을 가지고 있는 것처럼 테스트로 하여금 믿음을 가질 수 있다.
• 개발 후 테스트를 작성하게되면, 테스트에 대한 신뢰가 떨어진다.
• 이미 작성된 코드에서 테스트를 작성하라고 하면 실행 잘되는 케이스만 생각하게 될 것.

• velog
• Blog
• Github