Wiki Home

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

Growing Object-Oriented Software Guided By Tests

3장

4장

  • 최소한의 Infrastructure는 TDD 수행 전에 이미 구축되어 있어야 함.
  • 그래서 초기 구조를 설계하려면 시스템의 목적을 어느정도 이해해야 함.
  • 마감이 다가올 때 혼란과 불확실성을 초반으로 가져옴.

5장

  • 인수 테스트 = 전 구간 테스트
  • 실패하는 인수 테스트를 먼저 작성.
  • ‘ID, PASSWORD를 입력하고 로그인 버튼을 누르면 로그인이 된다’ 라는 요구사항을 실행되게 만들면 인수 테스트.

6장

  • Context는 세부사항(DB는 뭘 쓰고, 이건 웹을 위한거야 를 나타내는 부분).
  • 정보은닉은 안이 어떻게 생겼는지를 모름.
  • 캡슐화는 해당 객체의 데이터는 객체가 가진 프로시저(메소드)를 통해서만 바꿀 수 있음.
  • 정보은닉을 통해 캡슐화를 달성할 수 있음.
  • 단일책임원칙: 기능을 추가할 때 기존 클래스에 할 것이냐 새로운 클래스를 만들 것이냐를 결정할 때 도움이 됨.
  • 단일책임원칙을 준수하면 ‘와’, ‘나’ (AND) 같은 접속사를 쓰지 않고도 객체의 역할을 설명할 수 있어야 됨.
  • 다중 패러다임 언어: 외부에 드러나는 건 객체지향으로 내부는 함수형으로.

8장

  • 3rd Party Library를 사용할 때 내부 동작은 잘 모르기 때문에 mocking은 권장되지 않는다.
  • 어댑터 계층에서 3rd Party Library를 사용하는 객체의 입장에서 필요한 인터페이스를 정의하여 외부 API를 주도하는 코드를 테스트 한다.
  • 어댑터 계층은 되도록 얇게 유지하는 걸 권장한다.
  • 어댑터 계층의 인터페이스를 통해 어플리케이션과 외부 세계를 분리하는 것.
  • 반대로 어댑터 객체가 어플리케이션 객체를 콜백해야될 경우 어플리케이션 객체를 mocking 할 수도 있다.
  • 정확히는 어플리케이션 객체와 어댑터 객체 사이에도 인터페이스로 통신한다.(by 아샬님)
  • 사실 아직 mocking에 대한 경험이 부족해서인지 해설을 듣고서야 조금 알 것 같았다.
  • 핵심은 3rd Party Library와 같이 완벽히 제어하기 힘든 부분에 대해선 mocking을 자제하란 것이다.

12장

  • 동작하는 골격이란게 CI/CD까지 구축해야되는 게 아님.
  • 핵심은 눈으로 확인할 수 있는 최소한의 상태로 만드는 것.
  • 프로젝트 오너가 확인할 수 있어야 함.
  • 이터레이션 단위가 1주일이면 CI/CD를 구축하다가 1주일 날리면 안 됨.
  • 1주일 안에 안 될 거 같으면 버리고 기능 구현에 집중해서 동작하는 골격을 만들어야 함.
  • CI/CD는 말그대로 하면 좋은 것. 자동화일 뿐.