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

1부 서론

1장 테스트 주도 개발의 핵심은 무엇인가?

  • 사용중인 기술을 이해하지 못하기 때문에 동작 방식을 배우면서 프로젝트를 마무리해야 한다.

  • 피드백은 일찍 자주 받으면 좋다.

  • 코드를 가능한 단순하게 유지해야 한다. 작성보다 읽는 데 훨씬 많은 시간을 보내므로 거기에 맞게 최적화가 필요하다

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

  • 테스트 계층 구조

    • 인수 테스트: 전체 시스템이 동작하는가?

    • 통합 테스트: 변경할 수 없는 코드를 대상으로 코드가 동작하는가?

    • 단위 테스트: 객체가 제대로 동작하는가? 객체를 이용하기 편리한가?

2장 객체를 활용한 테스트 주도 개발

  • 객체는 협업하는 객체 망으로 구성되어 있다.

  • 값과 객체를 구분하는 것이 중요하다.

  • 묻지 말고 말하라. getter 를 연달아 호출하여 판단하지 마라.

  • 이웃하는 대체물을 mock 으로 대체하여 테스트하고자 하는 것만 테스트하라.

3장 도구 소개

  • 스킵

2부 테스트 주도 개발 과정

4장 테스트 주도 주기 시작

  • 동작하는 골격이란 전 구간을 대상으로 자동 빌드 * 배포 * 테스트를 할 수 있는 실제 기능을 가장 얇게 구현한 조각을 말한다.

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

  • 각 기능을 실패하는 인수 테스트 작성으로 시작하라. 이후 단위 테스트와 리팩터링을 통해 인수 테스트를 통과시킨다.

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

  • 처리해야 할 실패 케이스, 리팩터링, 기타 기술적인 작업을 메모장이나 색인 카드에 기록해두면 도움이 된다는 사실을 발견했다.

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

    • 시스템이 먼저 새로운 행위를 일으키게 하는 이벤트를 고려한다. 외부 이벤트를 받는 객체에서 중간 계층을 거쳐 중심 도메인으로 나아간 다음, 외부에서 확인 가능한 응답을 생성하는, 다른 객체에 위치한 객체에까지 이른다.

    • 새 도메인 모델 객체에 단위 테스트를 수행한 다음 애플리케이션의 나머지 부분에 해당 객체를 끼워 넣는 식으로 시작하고 싶을 수도 있다. 처음에는 이 방식이 더 쉬워 보이지만 나중에 통합 문제로 골머리를 앓을 가능성이 높다.

  • 테스트하기 어렵다면 주로 설계 개선이 필요하기 때문이다.

  • 실행 경로를 철저하게 테스트하는 것과 통합테스트 하는 것 사이에는 균형을 이루는 지점이 있다. 너무 큰 단위로 테스트를 수행하면 코드의 모든 가능한 경로를 시도하는 조합 폭팔(combinatorial explosion) 현상으로 개발이 중단될 것이다.

6장 객체 지향 스타일

  • 구조적인 세부 사항은 감추자.

  • 모든 객체는 단 한 가지 명확히 규정된 책임을 지녀야 한다.

  • 전체는 부분의 합보다 단순해야 한다.

  • 콘텍스트 독립성이라는 규칙은 한 객체가 정보를 너무 많이 감췄거나 잘못된 정보를 감췄는지 판단하는 데 유용하다. 각 객체가 해당 객체를 실행하는 시스템에 관해 아무것도 알지 못한다는 의미다.