test-driven-dev-python

• Test-Driven Development: By Example, Kent Beck 요약

TDD 참고자료

• TestDrivenDevelopment by Martin Fowler
• Test Driven Development (TDD) basic by Curt Park

테스트 주기(ch1, 47p)

1. 작은 테스트를 하나 추가한다.
2. 모든 테스트를 실행해서 테스트가 실패하는 것을 확인한다.
3. 조금 수정한다.
4. 모든 테스트를 실행해서 테스트가 성공하는 것을 확인한다.
5. 중복을 제거하기 위해 리펙토링한다.

조금 수정하기 = 최대한 빨리 초록색 보기(ch2, 56p)

• 가짜로 구현하기: 상수를 반환하게 만들고 진짜 코드를 얻을 때까지 단계적으로 상수를 바꾸어 나간다.
• 명백한 구현 사용하기: 실제 구현을 입력한다.

나(Kent Beck)는 보통 실무에서 TDD를 사용할 때 두 방법을 번갈아가며 사용한다.

코드 중복(ch.5, p71)

• 테스트를 빠르게 통과하기 위해서는 기존 코드를 복사 붙여넣기 할 수 있다.
• 하지만 중복이 사라지기 전에는 집에 가지 않겠다고 약속해야 한다.

TDD의 보폭(ch.9, p98)

지금과 같은 일은 TDD를 하는 동안 계속 해주어야 하는 일종의 조율이다. 종종걸음으로 진행하는 것이 답답한가? 그러면 보폭을 조금 넓혀라. 성큼성큼 걷는 것이 불안한가? 그럼 보폭을 줄여라. TDD란 조정해 나가는 과정이다. 정해진 올바른 보폭이라는 것은 존재하지 않는다.

컴퓨터에게 물어보기(ch.10, p103)

시스템에 대해 아는 지식을 기반으로 조심스럽게 생각해 보아야 할 문제다. 하지만 우리에겐 깔끔한 코드와, 그 코드가 잘 작동할 것이라는 믿음을 줄 수 있는 테스트 코드들이 있다. 몇 분 동안 고민하는 대신 그냥 수정하고 테스트를 돌려서 컴퓨터에게 직접 물어보자. 가끔은 컴퓨터에게 그냥 물어보는 것도 좋다.

Test는 최대한 작게 설정한다(ch.13)

• Personal Comment

Test Code를 작성하다보면 떠오르는 모든 예외상황을 Test Code로 작성하고 싶은 욕심이 든다. 하지만 Example에서는 항상 최대한 작은 크기의 Test를 작성하고, 그것을 통과하는 Code를 구현한 뒤, 리펙토링하는 사이클을 반복하고 있다. 떠오르는 예외 상황들은 TODO List로 관리한다. 다소 답답한 과정처럼 느껴지기도 하지만 한 번에 모든 예외를 처리하려는 경우 (1) 문제가 너무 복잡해지고 (2) 한 사이클에 소요되는 시간이 길어진다는 점 (3) 한 번에 많은 기능을 다루는 코드를 작성해야하고, 그에 따라 리펙토링의 범위도 늘어난다는 점 등의 단점이 발생한다.

개인적으로는 한 사이클에서는 명확히 규정할 수 있고, 통과 코드가 바로 떠오르는 정도의 작은 Test를 다루는 것이 좋다고 생각한다. 사람마다 느끼는 복잡성의 정도와 코딩 능력이 모두 다르기 때문에 모두에게 적용되는 절대적인 크기는 없지만 이러한 기준에 따라 Test Code를 작성하는 것이 TDD의 이상에 부합하는 코드 작성을 도와줄 수 있을 것이다.

또한 이러한 점에서 TODO List를 적극적으로 활용하는 것이 중요해 보인다. 떠오르는 예외 상황들은 곧바로 Test Code로 작성하지 않을 뿐이지 언젠가 모두 처리해야 할 것들이기 때문이다.

Test Code의 길이(ch.16, p145)

TDD로 구현할 땐 테스트 코드의 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다. TDD가 경제적이기 위해서는 매일 만들어내는 코드의 줄 수가 두 배가 되거나 동일한 기능을 구현하되 절반의 줄 수로 해내야 할 것이다. TDD가 자신의 방법에 비해 어떻게 다른지 측정해 보아야 할 것이다. 이때 디버깅, 통합 작업, 다른 사람에게 설명하는 데 걸리는 시간 등의 요소를 반드시 포함해야 한다는 것을 기억하기 바란다.

우리가 테스트를 작성하는 것은 단지 자신의 프로그래밍 경험을 더 재미있고 보람차게 하려고 하는 것만이 아니고, 후대가 우리의 천재성을 감상할 수 있는 로제타석이 되도록 하기 위함이기도 하다.