🍭 테스트 주도 개발로 배우는 객체 지향 설계와 실천

테스트 주도 개발 간단 정리

• TDD의 핵심 주기는 테스트를 작성하고 해당 테스트가 동작하게 만들 코드를 작성한다. 코드를 가급적 테스트한 기능의 단순한 구현으로 리팩터링한다. 이러한 과정을 반복한다.
• 다음은 테스트를 작성했을 때의 장점이다.
  • 다음 작업에 대한 인수 조건이 명확해진다.
  • 느슨하게 결합된 구성 요소를 작성할 수 있게 되어 격리된 상태에서, 더 높은 수준으로, 모두 결합된 상태로 구성 요소를 손쉽게 테스트할 수 있다.
  • 코드가 하는 일에 대한 실행 가능한 설명이 더해진다.
  • 완전한 회귀 스위트가 늘어난다.
• 다음은 테스트를 실행했을 때의 장점이다.
  • 콘텍스트를 선명하게 인지하는 동안 오류를 탐지한다.
  • 언제 작업이 충분히 완료됐는지 알게 되어 과도한 최적화를 하거나 불필요한 기능을 더하지 않게 된다.

실패하는 테스트 없이는 새 기능을 작성하지 말라.

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

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

불확실성은 일찍 드러내라

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

테스트에 귀를 기울이라

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

주기의 미세 조정

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

테스트를 먼저 작성하는 것이 설계에 어떻게 도움이 되는가

• 테스트로 시작한다는 것은 어떻게를 고려하기 전에 달성하고자 하는 바가 무엇인지를 기술해야 함을 의미한다. 이는 대상 객체에 대해 추상화를 올바른 수준으로 유지하는 데 기여한다.
• 단위 테스트를 이해 가능한 상태로 유지하려면 단위 테스트의 범위를 제한해야 한다.
• 단위 테스트를 위한 객체를 만들려면 해당 객체의 의존성을 전달해야 하는데, 이는 그러한 의존성이 어디에 있는지 알아야 한다는 의미다. 그러면 콘텍스트 독립성이 높아지는데, 이것은 단위 테스트를 수행하기에 앞서 대상 객체의 환경을 구성할 수 있어야 하기 때문이다.

테스트 주도 개발 기술에서 중요한 부분은 테스트 대상을 어디까지 바라봐야 하고, 결국 어떻게 모든 부분을 테스트할지 판단하는 것이다.

Chapter 20: 테스트에 귀 기울이기

TDD는 코드를 테스트하는, 즉 기능과 성능처럼 겉으로 드러나는 품질 속성을 검증하는 활동에 관한 것이다.

TDD는 코드의 내부 품질 속성에 관한 피드백, 즉 클래스의 결합도와 응집력, 명시적이거나 감춰진 의존성, 효과적인 정보 은닉 등 코드를 유지 보수 가능한 상태로 유지하는 품질 속성에 관한 작업이기도 하다.

테스트 악취에는 두 종류가 있다. 테스트 자체가 제대로 작성돼 있지 않은, 즉 테스트가 불분명하거나 불안정하게 작성된 경우와 테스트에서 대상 코드가 문제라고 강조되는 경우 (테스트하기 어려운 코드)이다.

너무 많은 예상 구문

테스트에 예상 구문이 너무 많으면 중요한 것이 무엇이고 실제로 뭘 테스트하는지 파악하기 어렵다.

테스트를 읽기 어렵게 하는 것은 모든 것이 예상 구문이라는 점으로 저눕 똑같이 중요해 보인다. 뭐가 중요하고 테스트를 통과하는지 분간할 수 없다.

예상 구문을 조금만 작성하고 너무 많은 예상 구문을 자제해야 한다.

Chapter 21: 테스트 가독성

테스트는 행위를 명확하게 표현해야 한다.
코드 가독성이 중요한 것과 같은 이유로 테스트 가독성도 중요하다.
테스트 코드는 제품 코드에서 하는 일이 무엇인지 반드시 기술해야 한다. 이것은 테스트 코드가 예상되는 결과의 예제로 사용하는 값에 관해서는 구체적이지만 해당 코드가 동작하는 방식에 관해서는 추상적인 경향이 있기 때문이다. 우리는 테스트 코드가 선언적으로 기술한 것처럼 읽히길 바란다.

테스트 이름은 기능을 기술한다 테스트 이름은 예상하는 결과와 객체의 행동, 시나리오의 동기에 관해 무언가를 말해줘야 한다.

Chapter 23: 테스트 진단

실패하는 설계

테스트의 핵심은 통과가 아니라 실패에 있다. 테스트 실패가 우리가 알아차리지 못했던 코드상의 암시적인 관계를 드러낸다.

절대 하지 말아야 할 일은 디버거를 열어서 테스트한 코드를 단계별로 훑어 내려가면서 불일치한 점을 알아내는 것이다. 그렇게 한다는 것은, 최소한 우리가 작성한 테스트가 요구 사항을 충분히 명확하게 표현하지 못했다는 것을 의미한다.

작고, 문제에 집중하고, 이름을 잘 지은 테스트

진단을 개선하는 가장 쉬운 방법은 각 테스트를 작으면서 문제에 초점을 맞춘 상태로 유지하고 테스트에 가독성 있는 이름을 부여하는 것이다.

Chapter 24: 테스트 유연성

• 테스트 불안정성의 공통적인 원인은 다음과 같다.
  • 테스트가 시스템에서 관련이 없는 부분이나 테스트 대상 객체에 무관한 행위와 너무 긴밀하게 결햅돼 있다.
  • 테스트가 대상 코드의 예상 행위를 과도하게 기술해서 필요 이상으로 제약한다.
  • 여러 테스트에서 동일한 제품 코드의 행위를 시험할 때 중복이 생긴다.
• 테스트 불안정성은 시스템 설계와도 관련이 있는데 어떤 객체가 의존성이 너무 많거나 해당 객체의 의존성이 감춰져 있어 환경과 분리하기가 어렵다면 해당 객체의 테스트는 객체와 동떨어진 부분이 변경될 때 실패할 것이다.
• 테스트 가독성과 회복력은 뗄 수 없는 관계며, 문제에 집중하고, 명료한 준비 사항을 갖추고 있으며, 중복이 최소화된 테스트는 이름을 짓기가 쉽고 테스트 목적이 분명하게 드러난다.