[17장] Money 회고
다음에 할일
-메타포:설계 구조에 미치는 메타포
-JUnit 사용도
-코드 메트릭스(metrics)
-프로세스:빨강/초록/리팩토링
-테스트의 질
[다음에 할일은 무엇인가]
지저분한 중복 처리
보통 클래스가 인터페이스로 바뀌는 일이 잦은데, 그 반대로 바뀌는 것은 일반적인 방향이 아니다.
난 “끝났다”는 말을 믿지 않는다. TDD를 완벽을 위한 노력의 일환으로 사용할 수도 있겠지만 그건 TDD의 가장 효과적인 용법이 아니다. 만약 시스템이 크다면, 당신이 늘 건드리는 부분들은 절대적으로 견고해야 한다. 그래야 나날이 수정할 때 안심할 수 있기 때문이다.
작업을 끝낸 후에 스몰토크의 스몰린트(SmallLint) 같은 코드 감정(code critic) 프로그램을 실행하길 좋아한다.
“다음에 할일은 무엇인가?”에 관련된 또 다른 질문은 “어떤 테스트들이 추가로 더 필요할까?”다. 때로는 실패해야 하는 테스트가 성공하는 경우가 있는데, 그럴 땐 그 이유를 찾아내야 한다. 또는 실패해야 하는 테스트가 실제로 실패하기도 하는데, 이때는 이를 이미 알려진 제한사항 또는 앞으로 해야할 작업 등의 의미로 그 사실을 기록해둘 수도 있다.
할일 목록이 빌 때가 그때까지 설계한 것을 검토하기에 적절한 시기다. 말과 개념이 서로 잘 통하는가? 현재의 설계로는 제거하기 힘든 중복이 있는가?
[메타포]
메타포라는 건 단지 이름들을 얻어 내는 데 필요한 것일 뿐이지 않은가? 절대 그렇지 않다.
[JUnit 사용도]
[코드 메트릭스]
코드에 대한 몇몇 통계
코드와 테스트 사이에 대략 비슷한 양의 함수와 줄이 있는 것을 알 수 있다.
모델 코드와 테스트 코드 사이의 대략적인 줄 수의 비율은 비슷하게 유지될 것이다.
회기성 복잡도(cyclomatic complexity)는 기존의 흐름 복잡도(flow complexity)와 같다. 테스트 코드에 분기나 반복문이 전혀 없기 때문에 테스트 복잡도는 1이다. 명시적인 흐름 제어 대신 다형성(polymorphism)을 주로 사용했기 때문에 실제 코드의 복잡도 역시 낮다.
[프로세스]
TDD의 주기는 다음과 같다.
-작은 테스트를 추가한다.
-모든 테스트를 실행하고, 실패하는 것을 확인한다.
-코드에 변화를 준다.
-모든 테스트를 실행하고, 성공하는 것을 화깅ㄴ한다.
-중복을 제거하기 위해 리팩토링한다.
리팩토링당 수정횟수는 두꺼운 꼬리 혹은 렙토쿠르토틱 프로파일(leptokurtotic profile)을 따른다.
[테스트의 질]
TDD의 부산물로 자연히 생기는 테스트들은 시스템의 수명이 다할 때까지 함께 유지돼야 할 만큼 확실히 유용하다. 하지만 이테스트들이 다음과 같은 다른 종류의 테스트들을 대체할 순 없다.
-성능 테스트
-스트레스 테스트
-사용성 테스트
<테스트에 사용되는 지표>
-명령문 커버리지(statement coverage):테스트의 시작점이다. TDD는 100%의 명령문 커버리지를 종교적으로 따른다.
-결함 삽입(defect insertion):코드의 의미를 바꾼 후에 테스트가 실패하는지 보는 것이다.
테스트 커버리지는..
전체 커버리지 수치는 프로그램의 서로 다른 경우를 테스트하는 테스트 수를 테스팅이 필요한 경우의 수(로직의 복잡도)로 나눈 것이다. 테스트 커버리지를 향상시키는 한 가지 방법은 더 많은 테스트를 작성하는 거다.
테스트 커버리지를 향상시키는 또다른 방법은 테스트의 수는 그대로 두면서 프로그램의 로직을 단순화하는 것이다. 리팩토링 단계가 종종 다음과 같은 효과를 가져온다. 조건문이 메시징으로 바뀌거나 아예 사라진다.
[최종 검토]
-테스트를 확실히 돌아가게 만드는 세가지 접근법: 가짜로 구현하기, 삼각측량법, 명백하게 구현하기
-설계를 주도하기 위한 방법으로 테스트 코드와 실제 코드 사이의 중복을 제거하기
-속도를 줄이고 높이는 식으로 테스트 사이의 간격을 조절할 수 있는 능력
댓글