📕 Test-Driven Development : By Example

• 켄트 백 지음

🗣 About TDD

• 테스트 주도 개발에서의 규칙 두 가지

  • 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
  • 중복을 제거한다.

• 프로그래밍 순서

  • 빨강 : 실패하는 작은 테스트 작성한다. 컴파일조차 되지 않을 수 있다.
  • 초록 : 빨리 테스트가 통과하게끔 한다.
  • 리팩토링 : 모든 중복을 제거한다.

1️⃣ Chapter 1 - 화폐 예제

• TDD의 리듬
  • 빠르게 테스트 추가한다.
  • 모든 테스트를 실행하고, 새로 추가한 것이 실패하는지 확인한다.
  • 코드를 조금 바꾼다..
  • 모든 테스트를 실행하고 전부 성공하는지 확인한다.
  • 리팩토링을 통한 중복을 제거한다.

⚡️ 1장 - 다중 통화를 지원하는 Money 객체

1. 테스트부터 작성하기

• 테스트를 작성할 때는 오퍼레이션의 완벽한 인터페이스에 대해 상상해보는 것이 좋다.
• 가능한 최선의 API에서 시작해서 거꾸로 작업한다.

2. 1장에서 실행한 TDD의 순서

• 작업해야 할 테스트 목록 만든다.
• 오퍼레이션이 외부에서 어떻게 보이길 원하는지를 코드로 표현한다.
• 스텁 구현을 통해 테스트를 컴파일한다.
  • 스텁 : 메서드를 호출하는 코드가 컴파일 될 수 있도록 껍데기만 만드는 것.
• 무조건 테스트에 통과시키도록 한다.
• 상수를 변수로 변경하여, 점진적으로 일반화한다.
• 새로운 할 일을 한 번에 처리하는 대신, 할 일 목록에 추가하고 넘어간다.

3. 작은 단계를 밟을 능력을 갖추는 것의 중요성

• 작은 단계를 연습하면서, 나에게 작은 단계를 밟을 능력이 있다는 것을 느낄 수 있다.
• 작은 단계로 작업하는 방법을 배우면, 저절로 적절한 크기의 단계로 작업할 수 있게 된다.

⚡️ 2장 - 타락한 객체

1. 나누어서 정복하기

목표는 작동하는 깔끔한 코드를 얻는 것이다. 이 목표는 도달하기 어려우므로, 일단 Divide and Conquer를 해보자.

• 우선, 작동하는 코드를 먼저 정복하고, 깔끔한 코드로 만드는 것이다.

2. 인터페이스와 테스트의 수정

새로운 테스트를 하려고 했을 때, 기존의 인터페이스와 테스트를 수정해야할 수 있다. 문제될 것은 없다!

• 어떤 구현이 올바른가에 대한 추측이 완벽하지 못한 것과 마찬가지로, 올바른 인터페이스에 대한 추측 역시 완벽하지 못하다. => 그러므로, 수정을 거듭할 수 있다.

3. 느낌을 테스트로 변환하기

• 부작용에 대한 느낌을 테스트로 변환하는 것은 TDD의 일반적인 주제이다.
• 일단 올바른 행위에 대한 결정을 내린 후에, 그 행위를 얻어낼 수 있는 최상의 방법에 대해 이야기할 수 있다.

4. 2장에서 실행한 TDD

• 설계상의 결함을 그 결함으로 인해 실패하는 테스트로 변환했다.
• 스텁 구현으로 컴파일이 될 수 있도록 한다.
• 올바르다고 생각하는 코드를 작성하여 테스트를 통과한다.

느낀점

• 우선 작동하게 만들기

  그동안 나는 깔끔한 코드를 먼저 작성하기 위해 고군분투한 것 같다. 처음부터 깔끔하기란 너무 어려운 것이었다. 우선 작동하는 코드를 먼저 만들고 난 후에, 깔끔한 코드로 만드는 것이 방법이라는 것을 알게되었다.

• 목표를 설정하기

  테스트 코드를 먼저 작성하는 이유가, "올바른 행위"와, "원하는 인터페이스"를 먼저 정의해야, 그 방법에 대해 생각해볼 수 있다는 것을 알게 되었다. 원하는 바를 명확하게 설정하고, 그것을 얻어내기 위핸 길을 찾아내야 하는 것 같다.

• 수정하는 것에 대한 두려움 없애기

  처음부터 완벽한 구현을 하는 것은 없는 것 같다. 구현을 하는 시기에는 좋은 설계를 위한 고민을 해야 한다. 하지만, 변화를 주어야 할 때는 이전의 구현에서의 잘못을 인정하고 수정할 수 있어야 하는 것 같다. 테스트와 인터페이스를 수정하는 것은 이상한 일이 아니었다.