🌈 Chapter 5: 테스트 주도 개발 주기의 유지

📚 각 기능을 인수 테스트로 시작하라

• 인수 테스트는 우리가 작성하려는 기능을 아직 시트엠에서 갖추지 못했다는 사실을 보여주고 그 기능이 완성되기까지 진생 상황을 반영한다.
• 인수 테스트를 작성할 때는 기반 기술의 용어가 아닌 응용 도메인에서 나온 용어만 이용한다.
• 인수 테스트는 단위 테스트를 거친 객체를 대상으로 통합 테스트를 수행할 뿐 아니라 프로첵트를 앞으로 나아가게 한다.

📚 회귀를 포착하는 테스트와 진행 상황을 측정하는 테스트를 분리하라

• 인수 테스트를 작성하면서 신기능을 묘사하는데 그 기능이 구현되기 전이라 인수 테스트는 실패할 것이다. 새 인수 테스트란 아직 마치지 않은 일을 서술한 것이기 때문이다.
• 인수 테스트를 빨간색에서 녹색으로 바꾸는 활동은 팀에서는 진행 상태를 측정할 수 있따.
• 인수 테스트를 통과하면 이제 해당 테스트는 완료된 기능을 나타내고 다시는 실패해서는 안 된다.
• 단위 테스트와 통합 테스트는 개발 팀을 보조하고 빠르게 실행돼야 하며, 항상 통과해야 한다.
• 요구 사항이 바뀌면 거기에 영향을 받은 인수 테스트를 회귀 테스트 그룹에서 빼내서 진행 중인 테스트 그룹으로 읆긴 후 새 요구 사항을 반영토록 수정한 다음, 해당 테스트를 다시 통과하게끔 시스템을 변경해야 한다.

📚 테스트를 가장 간단한 성공 케이스로 시작하라

• 우리는 가장 간단한 성공 케이스로 테스트를 시작하길 좋아한다. 해당 테스트가 동작하면 솔루션의 실제 구조에 관해 더 좋은 생각이 떠오를 테고, 그 과정에서 발견한 발생 가능한 실패를 처리하는 것과 이후의 성공 케이스 사이에서 우선순위를 가늠해볼 수 있다.
• 처리해야 할 실패 케이스, 리팩터링, 기타 기술적인 작업을 메모장이나 색인 카드에 기록해 두면 도움이 된다. 이렇게 하면 세부 사항을 빠뜨리지 않고도 당면 과제에 집중할 수 있다. 기능은 기록해둔 목록의 항목에 모두 선을 그어야 비로소 마무리된다.

📚 읽고 싶어 할 테스트를 작성하라

• 테스트가 잘 읽히면 테스트를 그 다음으로 지원하는 기반 구조를 만든다.
• 테스트가 어떻게 해야 할지 기술하는 명확한 오류 메시지를 보이면서 예상대로 실패하면 보조적인 역할을 하는 코드를 충분히 구현했다는 사실을 알게 된다. 그러면 해당 테스트를 통과시키는 코드를 작성하기 시작하면 된다.

📚 테스트가 실패하는 것을 지켜보라

• 테스트가 예상과 다른 식으로 실패하면 뭔가를 잘못 이해했거나 코드가 완성되지 않았다는 뜻으로 부족한 부분을 고친다. 우리는 적당한 실패를 만나면 진단 정보가 도움이 되는지 확인한다. 실패에 대한 설명이 명확하지 않으면 코드가 몇 주간 망가져 있을 동안 누군가 고생해야 할 것이다. 오류 메시지가 코드와 관련된 문제로 우리를 이끌 때까지 테스트 코드를 조정하고 테스트를 재실행한다.
• 오류 메시지를 검사해야 하는 이유
  1. 오류 메시지는 현재 작업 중인 코드에 대한 가정을 확인한다.
  2. 의도에 대한 표현을 강조하는 것은 신뢰성 있고 유지하기 쉬운 시스템을 개발하는 데 필수고, 테스트와 실패 메시지가 여기에 해당한다. 유용한 진단 정보를 생성하는 고생을 감내하면 테스트, 코드에서 해야 할 일이 뭔지 분명하게 하는 데 도움이 된다.

📚 입력에서 출력 순서로 개발하라

• 기능에 대한 전 구간 테스트는 새로운 행위를 일으키게 하는 이벤트가 도착하는 것을 흉내 낼 것이다. 시스템 경계에서는 이 이벤트를 다루고자 객체를 여러 개 작성해야 할 것이다. 그럴 때 이 객체들이 자기 책임을 수행하고자 시스템의 나머지 부분에 존재하는 서비스를 지원할 필요가 있음을 알게 됐다. 우리는 더 많은 객체를 작성해 이러한 서비스를 구현하고 새 객체에 필요한 서비스가 뭔지 파악한다.
• 이런 식으로 시스템을 처음부터 끝까지 만들어 나간다.
  1. 외부 이벤트를 받는 객체에서 중간 계층을 거쳐 중심 도메인 모델로 나아간다.
  2. 외부에서 확인 가능한 응답을 생성하는 다른 경계에 위치한 객체에까지 이른다.

📚 메서드가 아닌 행위를 단위 테스트하라

• TDD를 도입하는 많은 개발자가 초기에 작성한 테스트를 나중에 되돌아봤을 때 이해하기 어렵다는 사실을 발견하는데, 흔히 저지르는 실수 한 가지는 바로 메서드 테스트를 생각한다는 데 있다.
• 테스트 대상 객체에서 제공해야 하는 기능에 집중할 때 더 잘할 수 있으며, 각각은 이웃 객체와의 협업이나 여러 메서드 호출이 필요할지도 모른다. 해당 클래스의 코드를 통해 모든 실행 경로를 시험하는 방법이 아니라 그 클래스로 목적을 달성하는 방법을 알아야 한다.
• 테스트 이름을 지을 때는 테스트 중인 시나리오에서 객체가 어떻게 동작하는지 설명하는 이름을 선택하는 것이 도움이 된다.

📚 테스트에 귀를 기울이라

• 테스트하기 어렵다면 주로 설계 개선이 필요하기 때문이다. 지금 당장 코드를 테스트하기 어렵게 만드는 구조 때문에 나중에도 코드를 변경하기 어려울 것이다. 시간이 지나면 변경하기가 더 어려울 텐데 코드를 작성할 때 무슨 생각을 했는지 잊어버리기 때문이다.
• 이 경우 테스트를 작성하는 과정을 잠재적인 유지 보수 문제를 조기에 알려주는 귀중한 경고로 여기고 그 힌ㄷ트를 이용해 아직 심각하지 않을 때 문제를 해결한다. 때문에 실패한 테스트를 작성하기 어렵다면 제품의 코드의 설계를 다시 살펴보고 앞으로 나아가기 전에 리팩터링한다.

📚 주기의 미세 조정

• 너무 큰 단위로 테스트를 수행하면 코드의 모든 가능한 경로를 시도하는 조합 폭발 현상으로 개발이 중단될 것이다.
• 반면 테스트 단위를 너무 세밀하게 잡으면 테스트하기는 쉽지만 함께 동작하지 않는 객체에서 유래하는 문제를 놓치고 말 것이다.
• 단위 테스트와 통합 테스트 사이에 얼마나 해야 할지에 대한 답은 팀이 처한 상황과 팀에 둘려싼 환경에 따라 달라진다. TDD의 테스트 부분에서 얻을 수 있는 최고의 혜택은 코드를 망가뜨리지 않고도 변경할 수 있다는 자신감이다. 까다로운 부분은 그러한 자신감이 정당한지 확인하는 것이다.
• 그래서 우리는 주기적으로 TDD가 얼마나 도움이 되는지 되짚어보고 취약한 부분을 찾아보며, 테스트 전략을 조정한다. 로직에서 성가신 부분에는 단위 테스트가 더 필요할 수도 있다. 처리하지 않은 예외에는 통합 수준의 테스트가 더 필요할지도 모른다. 그리고 예상치 못한 시스템 실패에는 조사가 더 필요하거나 어쩌면 테스트를 더 철저하게 해야 할 것이다.