이전까지는 예제 없이 정리가(설명이) 안되는 것들이 많았지만, 이제는 구체적인 예제는 없이 TDD의 개념과 진행 방향에 대해서만 정리하도록 한다.
chapter 15
하나씩 원하는 테스트를 작성한다.
이 테스트는 생각이 나는대로 수도 코드처럼 코드를 작성한다.
컴파일과 테스트를 통과하는 방향으로 수정해나가는 것이기 때문에, 컴파일 에러가 날 수 있다.
컴파일 에러가 나는 것을 두려워하는 것이 아니라, 중요한 것은 한 번에 하나씩 확실하게(완벽하라는 건 아니다. 빠르게가 더 중요하니까) 고쳐나가는 것이다.
우리가 할 일이 무엇인지를 알려주는 것이 컴파일과 테스트이다.
중복을 제거하고 상속이나 범용성을 가질 수 있는 코드들을 변경하면서 다시 고치는 것이다.
변경 후에 영향을 미치는 다른 부분들을 컴파일러가 알려주면 그 부분도 수정한다.
chapter 16
테스트도, 차후에 읽을 때 이해하기 좋게 코드를 짠다. 효율적인 TDD
- TDD를 쓰고 개발량이 증가한다.
- TDD를 쓰고 동일 기능을 구현하는데 필요한 라인 수가 감소한다.
- 디버깅, 통합 작업, 다른 사람한테 설명하는데 걸리는 시간 등을 합친 것보다 경제적이다.
chapter 17
이 장에서는 어떻게 해 나가야 하는지와 테스트를 돌아본다.
다음에 해야할 일은 무엇일까? 생각이 들 때
- SmallLint 같은 code critic 프로그램을 실행하는 것도 좋다.
- 내가 놓친 것을 잡아줄 수 있기 때문에.
- 어떤 테스트들이 추가로 더 필요할까? 생각하는 것.
- 실패해야하는 테스트가 성공하는 경우.
- 실패해야하는 테스트가 실패하는 경우.
- 막무가내로 개발하며 해야할 일을 적어놓은 리스트를 비우느 ㄴ것.
- 말과 개념이 잘 통하는지 확인
- 현재 설계로 제거하기 어려운 중복이 있는지 확인.
메타포
메타포는 클래스 명 등을 정하는 아이디어와도 같은 것인데, 메타포를 통해 설계가 완전히 바뀔 수 있다. 즉, 중요하다. 이 책에서 예시를들고 있는 expression을 통한 통화 계산은 나도 생각을 못한 것이었는데, 저자도 10 ~ 20번의 금전 관련 프로그램에 대한 설계들을 통해 얻은 통찰이라고 한다.
코드와 테스트 비교
- 코드와 테스트 사이에 비슷한 수준의 함수 개수와 라인 수가 유지 된다.
- 테스트 코드는 공통된 테스트를 뽑아내는 작업으로 라인 수를 줄일 수 있다.
- 코드 복잡도를 보면 테스트 코드는 코드 복잡도가 1이다.
- 분기나 반복이 전혀 없기 때문이다.
테스트의 질
TDD의 부산물로 자연스레 생기는 테스트들은 시스템과 함께 유지되야 할 만큼 유용하다. 하지만 이 테스트들이 다른 종류의 테스트를 대체할 수는 없다.
- 성능 테스트
- 스트레스 테스트
- 사용성 테스트
테스트의 질을 가늠하는 지표
- 명령문 커버리지(statement coverage)
- TDD는 100%의 명령문 커버리지를 따르게 되는데, 모든 함수들이 테스트 케이스에 의해 검증된다는 것을 의미한다. JProbe를 통해 확인할 수도 있다.
- 결함 삽입(defect insertion)
- 코드의 내용을 바꾼 후 테스트가 실패하는지 보는 것이다. 수동으로 할 수 있지만 Jester를 통해 확인할 수도 있다.
- 그니까 테스트 통과하려고 거짓말 한 것들을 거르기 위한 것으로 보인다.
테스트 커버리지를 향상시키는 법
- 더 많은 테스트 케이스를 작성하는 것.
- 예를 들면 TDD 개발자는 6개의 테스트를 작성한다면, 전문 테스터는 65개의 테스트를 작성한다.
- 프로그램의 로직을 단순화 하는 것.
- 코드를 줄여서 테스트가 다양한 경우를 다루게 한다.