이전까지는 예제 없이 정리가(설명이) 안되는 것들이 많았지만, 이제는 구체적인 예제는 없이 TDD의 개념과 진행 방향에 대해서만 정리하도록 한다.

chapter 15

하나씩 원하는 테스트를 작성한다.
이 테스트는 생각이 나는대로 수도 코드처럼 코드를 작성한다.
컴파일과 테스트를 통과하는 방향으로 수정해나가는 것이기 때문에, 컴파일 에러가 날 수 있다.
컴파일 에러가 나는 것을 두려워하는 것이 아니라, 중요한 것은 한 번에 하나씩 확실하게(완벽하라는 건 아니다. 빠르게가 더 중요하니까) 고쳐나가는 것이다.
우리가 할 일이 무엇인지를 알려주는 것이 컴파일과 테스트이다.
중복을 제거하고 상속이나 범용성을 가질 수 있는 코드들을 변경하면서 다시 고치는 것이다.
변경 후에 영향을 미치는 다른 부분들을 컴파일러가 알려주면 그 부분도 수정한다.

chapter 16

테스트도, 차후에 읽을 때 이해하기 좋게 코드를 짠다. 효율적인 TDD

  1. TDD를 쓰고 개발량이 증가한다.
  2. TDD를 쓰고 동일 기능을 구현하는데 필요한 라인 수가 감소한다.
  3. 디버깅, 통합 작업, 다른 사람한테 설명하는데 걸리는 시간 등을 합친 것보다 경제적이다.

chapter 17

이 장에서는 어떻게 해 나가야 하는지와 테스트를 돌아본다.

다음에 해야할 일은 무엇일까? 생각이 들 때

  1. SmallLint 같은 code critic 프로그램을 실행하는 것도 좋다.
    • 내가 놓친 것을 잡아줄 수 있기 때문에.
  2. 어떤 테스트들이 추가로 더 필요할까? 생각하는 것.
    • 실패해야하는 테스트가 성공하는 경우.
    • 실패해야하는 테스트가 실패하는 경우.
  3. 막무가내로 개발하며 해야할 일을 적어놓은 리스트를 비우느 ㄴ것.
  4. 말과 개념이 잘 통하는지 확인
  5. 현재 설계로 제거하기 어려운 중복이 있는지 확인.

메타포

메타포는 클래스 명 등을 정하는 아이디어와도 같은 것인데, 메타포를 통해 설계가 완전히 바뀔 수 있다. 즉, 중요하다. 이 책에서 예시를들고 있는 expression을 통한 통화 계산은 나도 생각을 못한 것이었는데, 저자도 10 ~ 20번의 금전 관련 프로그램에 대한 설계들을 통해 얻은 통찰이라고 한다.

코드와 테스트 비교

  • 코드와 테스트 사이에 비슷한 수준의 함수 개수와 라인 수가 유지 된다.
    • 테스트 코드는 공통된 테스트를 뽑아내는 작업으로 라인 수를 줄일 수 있다.
  • 코드 복잡도를 보면 테스트 코드는 코드 복잡도가 1이다.
    • 분기나 반복이 전혀 없기 때문이다.

테스트의 질

TDD의 부산물로 자연스레 생기는 테스트들은 시스템과 함께 유지되야 할 만큼 유용하다. 하지만 이 테스트들이 다른 종류의 테스트를 대체할 수는 없다.

  • 성능 테스트
  • 스트레스 테스트
  • 사용성 테스트

테스트의 질을 가늠하는 지표

  • 명령문 커버리지(statement coverage)
    • TDD는 100%의 명령문 커버리지를 따르게 되는데, 모든 함수들이 테스트 케이스에 의해 검증된다는 것을 의미한다. JProbe를 통해 확인할 수도 있다.
  • 결함 삽입(defect insertion)
    • 코드의 내용을 바꾼 후 테스트가 실패하는지 보는 것이다. 수동으로 할 수 있지만 Jester를 통해 확인할 수도 있다.
    • 그니까 테스트 통과하려고 거짓말 한 것들을 거르기 위한 것으로 보인다.

테스트 커버리지를 향상시키는 법

  • 더 많은 테스트 케이스를 작성하는 것.
    • 예를 들면 TDD 개발자는 6개의 테스트를 작성한다면, 전문 테스터는 65개의 테스트를 작성한다.
  • 프로그램의 로직을 단순화 하는 것.
    • 코드를 줄여서 테스트가 다양한 경우를 다루게 한다.