TDD 테스트 주도 개발

Test Driven Development

 

1. TDD의 주된 이익

코드를 깨끗하게 유지하도록 치열하게 싸우지 않으면 시스템은 점점 퇴화한다. 코드를 재빠르게 추가할 수는 있지만 처음에는 good code 라기보다는 not so great code 일 가능성이 높다. TDD를 잘 따른다면 구현하는 실질적인 모든 사례에 대해 단위테스트를 작성하게 된다. 단위 테스트는 코드를 지속적으로 발전시킬 수 있는 자유를 준다.

 

작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야 한다. 작성할 코드를 묘사하는 테스트를 설계해야 한다. 이러한 역 방향 접근법은 단위 테스트 전략의 핵심이다. 

 

 

2. 단순하게 시작

TDD는 세 부분의 사이클로 구성된다.

- 실패하는 테스트 코드 작성하기
- 테스트 통과시키기
- 이전 두 단계에서 추가되거나 변경된 코드 개선하기

시스템에 추가하고자 하는 동작을 정의하는 테스트 코드를 제일 먼저 작성한다. 그 다음 테스트가 통과할 수 있도록 도메인 코드를 작성한다. 테스트는 점진적으로 작성한다. 작은 테스트를 먼저 작성하고 그 후에 작은 코드를 작성한다. 오류가 발생하지 않고 컴파일 되는 것으로 충분하다.

 

→ 테스트가 실패해야 기대하는 동작이 아직 시스템에 존재하지 않는다는 것을 보여줄 수 있다.

 

 

3. 또 다른 증분(Increment) 추가

실패하는 각 테스트에 대해 그 테스트를 통과할 수 있는 코드만 추가하라. 즉 가능한 작은 증분(increment)를 추가하는 것이다. 테스트가 나타내는 '명세'를 정확히 코딩하고 테스트가 모두 통과한다면 잠재적으로 코드를 배포할 수 있다. 추측에 근거한 개발은 잠재적으로 낭비를 초래한다.

 

TDD 사이클에 따르면 적은 양의 코드로 실패하는 테스트를 만드는 것이 실용적이라는 것이다. 통과하는 많은 테스트 코드를 작성하는 것이 좋은 일이 아니다는 뜻이다. 적절한 피드백을 받기 전에 많은 양의 코드를 작성하는 것은 옛 방식이다.

 

(직역된 책이라 이해가 힘들 때가 있다)

 

 

4. 테스트 정리

테스트는 짧고 깔끔해야 한다. 기존에 작성했던 코드를 리팩토링하여 다듬는 과정을 거친다.

 

@BeforeEach 메서드에 공통 초기화를 넣고 간결하고 명시적인 표현으로 리팩토링을 진행한다. 대부분의 리팩토링은 쉽지만 효과가 크다. 작은 코드 조각을 의도를 알 수 있는 이름의 도우미 메서드로 추출하는 것도 테스트를 향상시킨다.

 

 

5. TDD의 리듬

TDD의 사이클은 테스트-코드-리팩토링으로 짧다. 각 단계에서 추가되거나 변경된 코드 증분도 적다. 약 10분 정도의 시간 제한을 걸어보고, 10분 동안 어떤 긍정적인 피드백(테스트 통과)을 받지 못했다면 작업 중인 코드는 폐기하고 다시 좀 더 작은 단계로 도전해 보라. 나쁜 코드는 버려야 한다. TDD를 도입하면 설게에 대한 생각하는 방식이 바뀌게 된다.