🌈 Chapter 4: 테스트 주도 주기 시작

📚 우선 동작하는 골격을 대상으로 테스트하라

• 첫 인수 테스트를 작성하고 통과하는 일의 어려움은, 도구를 마련하고 동시에 그렇게 마련한 도구로 테스트를 하면서 기능까지 구현하기가 어렵다는 데 있다. 안정적이지 못한 개발 환경의 증상 한 가지는 뭔가가 실패했을 때 가장 먼저 어디를 살펴봐야 할지 마땅치 않다.
• 이 같은 최초 기능의 역설은 규모가 작은 두 문제로 쪼개면 해결할 수 있다. 먼저 동작하는 골격을 대상으로 빌드, 배포, 테스트하는 방법을 파악한 다음, 그 기반 구조를 이용해 유의미한 첫 기능에 대한 인수 테스트를 작성한다. 그 후에는 시스템의 나머지 부분을 대상으로 테스트 주도 개발을 진행할 수 있게 모든 것이 제자리에 놓일 것이다.
• 동작하는 골격이란 전 구간을 대상로 자동 빌드, 배포, 테스트를 할 수 있는 실제 기능을 가장 앏게 구현한 조각을 말한다.
• 테스트 과정에 배포 단계를 포함하는 것은 두 가지 이유에서 굉장히 중요하다.
  1. 배포 단계는 손수 해서는 안 될, 오류가 발생하기 쉬운 활동이므로 실제 환경에 배포해야 할 때까지는 스크립트를 철저하게 검증해야 하기 때문이다.
  2. 배포 단계에서는 개발 팀이 조직의 다른 부문과 접촉하기도 하며, 운영이 실제로 어떻게 되는지도 배워야 하기 때문이다.
• 실제로 전 구간을 대상으로 수행되는 테스트는 달성하기 어려울 수도 있으므로 실제 시스템에서 수행할 기능과 시스템이 수행되는 환경에 대해 현재 알고 있는 사항을 구현한 기반 구조에서 시작해야 한다. 하지만 이 방식은 일을 마치기 전까지는 그저 임시방편에 불과하며, 실제로 전 구간을 대상으로 테스트를 수행하기 전까지는 미처 파악하지 못한 위험이 도사리고 있다.
• 동작하는 골격과 그것을 보좌하는 기반 구조는 테스트 주도 개발을 시작하는 방법을 도와주기 위해 존재하는 것이다. 동작하는 골격은 전 구간에 걸친 인수 테스트 솔루션을 완성하는 것으로 나아가는 첫 걸음에 지나지 않는다.

📚 동작하는 골격의 외형 결정

• 동작하는 골격을 개발한다는 것은 애플리케이션의 개괄적인 구조를 결정하기 시작한다는 의미다. 구체적일 필요가 없지만 계획한 첫 출시를 달성하는 데 주요 시스템 컴포넌트와 그러한 컴포넌트의 상호 작용 방식에 대한 대략적인 그림이 필요하다.
• 이 같은 초기 구조를 설계하려면 시스템의 목적을 어느 정도 이해해야 한다. (클라이언트의 요구 사항)
• 동작하는 골격의 핵심은 팀에서 자신들의 해법(팀에서 코드 작성을 시작하기 전에 반드시 취해야 할 필수적인 의사 결정)을 전체적으로 조망하는 데 이바지하게끔 첫 테스트를 작성하는 과정을 활용해 프로젝트의 맥락을 짚어내는 데 있다.

문제 이해 -> 대략적인 설계(아키텍처) -> 자동화(빌드, 배포, 전 구간 테스트) -> TDD

• 실제 피드백을 토대로 배우고 개선해 나가는 과정을 시작할 수 있게 TDD 주기를 시작하는 데 필요한 최소한의 의사 결정을 내린다.

📚 피드백 소스 구출

• 애플리케이션 설계에 대해 내린 의사 결정이나, 애플리케이션 설계가 근거하는 가정의 옳고 그름에 대해서는 아무것도 보장할 수 없다. 그저 최선을 다할 뿐이며 현재 밟고 있는 절차에 피드백을 적용해 최대한 빨리 의사 결정이나 가정을 검증하는 데 의지할 뿐이다. 동작하는 골격을 구현하고자 제작한 도구는 이러한 학습 과정을 보조하기 위해 존재한다.
• 이상적인 상태는 팀에서 정기적으로 운영 시스템에 릴리즈할 때다. 이렇게 하면 시스템의 이해관계자들이 시스템이 자신들의 요구에 얼마나 부합하는지에 반응할 수 있고, 동시에 우리는 시스템 구현을 평가할 수 있다.
• 우리는 빌드 및 테스트 자동화를 활용해 시스템 품질에 관한 피드백을 받는다.
• 가장 큰 혜택은 뭘 배우든 거기에 맞춰 시스템을 변경할 수 있으리라는 점이다. 뭐든 테스트를 먼저 작성한다는 것은 철저한 회귀 테스트 모음을 갖게 된다는 것을 의미하기 때문이다. 어떤 테스트도 완벽하지 않지만 견고한 테스트 모음이 있으면 중대한 변경을 안전하게 할 수 있다.

📚 불확실성은 일찍 드러내라

• 통합을 나중에 하는 방식의 경우 어떤 일이 일어날지 예측하기가 불가능한데, 팀에서 엄청나게 많은 각 부분을 제한된 시간에 짜맞춰야 하고 실패한 부분을 고치는 일도 감안해야 하기 때문이다.
• 반면에 점진적인 개발을 잘 운영하면 처음에는 불안정한 상태로 시작하지만 일부 기능을 구현하고 프로젝트 자동화가 구축되고 나면 반복적인 과정으로 안정화된다. 프로젝트가 인도 단계에 접어들면 결국 꾸준히 기능이 만들어질 테고 아마 처음으로 출시하기 전에는 활동량이 굉장히 많을 것이다. 배포와 업그레이드처럼 평범하지만 깨지기 쉬운 작업은 모두 자동화되어 알아서 굴러갈 것이다.
• 테스트 주도 개발의 이 같은 측면은 다른 측면과 마찬가지로 직관적이지 않게 보일지도 모르겠지만 지금까지 늘 충분한 시간을 들여 시스템 기반을 대상으로 구조를 잡고 자동화할 만한 가치가 있다.