자바와 JUnit을 활용한 단위테스트_12

12장. 테스트 주도 개발.

작성하려는 코드가 있다면 항상 먼저 어떻게 그 코드를 테스트할지 고민해야 한다.
코드를 작성한 후에 어떻게 테스트할지 고민하기보다 작성할 코드를 묘사하는 테스트를 설계해야 한다.
TDD에서 단위 테스트를 시스템의 모양을 잡고 통제하는 도구로 활용해야 한다.
단위 테스트는 소프트웨어를 어떻게 만들어야 할지에 관한 잘 훈련된 사이클의 핵심적인 부분이다.
따라서 TDD를 채택하면 소프트웨어 설계는 달라지고 아마도 더 좋아질 것이다.

---

TDD의 주된 이익

단위 테스트를 사휘에 작성하여 얻을 수 있는 가장 명확한 이익은 코드가 예상한 대로 동작한다는 자신감인데 TDD에서도 동일하다.
또한 TDD를 잘 따른다면 구현하는 실질적인 모든 사례에 대해 단위 테스트를 작성하게 된다.
이런 단위 테스트는 코드를 지속적으로 발전시킬 수 있는 자유를 준다.

단순하게 시작

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

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

첫 번째 단계는 시스템에 추가하고자 하는 동작을 정의하는 테스트 코드를 작성하는 것이다.
이때 실패하는 테스트 코드를 작성하고 기대하는 동작이 아직 시스템에 존재하지 않는다는 것을 보여 줄 수 있다.
TDD를 할 대 값비싸고 나쁜 가정들을 피하기 위해 항상 테스트가 먼저 실패하는지 관찰하자.

실패하는 테스트에 대해 그 테스트를 통과할 수 있는 코드만 추가해준다. 즉 가능한 가장 작은 증분을 추가하는 것이다.
테스트가 모두 통과한다면 잠재적으로 코드를 배포할 수 있다.
이 지점에서 테스트는 시스템이 무엇을 하는지 문서화도 할 수 있다.

TDD 사이클에 따르는 실용적인 관점에서 가장 작은 양의 코드를 작성하는 것은 먼저 실패하는 또 다른 테스트를 만들 수 있다는 의미이다.
필요한 것보다 더 많은 코드를 작성하는 것은 즉시 통과할 수 있는 많은 테스트를 스스로 만들 수 있다는 의미이다.
좋은 일인 것 같지만 적절한 피드백을 받기 전 많은 양의 코드를 작성하는 옛 방식으로 돌아가는 것이다.
결함 있는 코드를 작성할 때는 바로 알아내는 것이 더 좋다.

테스트 정리

TDD의 아름다움은 모든 기능에 대해 먼저 테스트를 작성한다는 것이고,
그것은 항상 막 작성한 코드를 리팩토링하고 정리할 수 있다는 자신감을 준다.
또한 대부분의 리팩토링은 쉽지만 효과가 크다. 예를 들어 변수 이름을 변경하는 것 만으로도 커다란 정보를 줄 수 있다.
작은 코드 조각을 의도를 알 수 있는 이름의 도우미 메서드로 추출하면 마찬가지로 테스트를 향상하는 데 많은 도움이 된다.

또 다른 작은 증분

TDD로 생각하는 부분의 일부는 작성할 필요가 있는 다음 테스트를 결정하는 것이다.
프로그래머로서 임무는 코드가 다루어야 하는 모든 가능한 순열과 시나리오를 이해하는 것이다.
TDD로 성공하려면 이들 시나리오를 테스트로 만들고 각 테스트를 통과하게 만드는 코드 증분을 최소화하는 순으로 코드를 작성하는 것이다.

인터페이스 확장

테스트를 리팩토링하게 되면 TDD 사이클을 짧게 유지하기에 용이하다.
각 테스트에 나오는 임시 result 변수를 제거한다.
그렇게 하면 AAA를 조금 위반하긴 하지만 괜찮다.
AAA는 불변의 법칙이 아니기 때문이다. 특히 테스트의 반복적 성질로 봤으르 때 result 임시 변수는 가치가 없고 없어도 잘 읽힌다.

문서로서의 테스트

테스트 주도 클래스를 잘 이해하려면 테스트명부터 살펴보자.
포괄적인 테스트 이름의 집합은 그 클래스의 의도된 용량을 전체적인 관점 요약으로 제공한다.
또한 테스트 하려는 동작을 테스트 클래스의 이름으로 넣으면 개별 테스트 이름에서 중복되는 정보를 제거할 수 있다.
정기적으로 테스트 이름이 서로 잘 어울리는지 확인하자.

TDD의 리듬

TDD의 사이클은 짧다. 
10분 동안 어떤 긍정적인 피드백(테스트 통과)을 받지 못했다면 작업 중인 코드는 폐기하고 다시 좀 더 작은 단계로 도전해 보자.