1/9 TIL 테스트, 리팩토링, 볼링게임

테스트의 효과

• 단순한 검증이라기보다는 설계의 문제다.
• 프로그래머가 수정 중 중요한 것을 망가뜨릴 염려를 없앨 수 있다.
• 프로그래머가 다른 관점에서 문제를 해결할 수 있다. - 호출자 관점에서 보게 된다. -> 편리하게 호출할 수 있는 소프트웨어를 설계하게 된다.
• 반드시 테스트 가능한 프로그램을 설계하도록 강제할 수 있다. -> 소프트웨어를 다른 환경과 분리하도록 강제한다.
• 테스트 자체가 문서화다.

인수테스트

인수 테스트는 기능 요소의 궁극적인 문서화 형태다.
인수테스트 고려가 시스템의 아키텍처에 큰 영향을 준다. -> 인수테스트를 스크립트나 XML로 하기 위해 자연스럽게 트랜잭션 소스, 출력 매커니즘 등을 분리하게 된다.

리팩토링

모듈을 읽기 쉽고 변경하기 쉽게 만들기 위해 필요한 것은 원칙과 패턴에 더해 주의력과 훈련이 필요하다.

모듈의 세가지 기능

• 기능대로 동작하기
• 가능한 간단하게 변경 가능
• 읽는 사람과의 의사소통

책에 나온 리팩토링 순서 예

1. 통계적 테스트 세트가 있는 테스트 코드를 작성한다
2. 내부 함수를 정리한다. 한줄짜리 함수까지 만들기도 한다.
3. 내부 함수는 일일히 테스트 하지는 않는다. (외부로 노출된 것만 하면 될 듯하다.)
4. 중간에 효율성을 위해 로직을 수정하면서 걱정된다면 , 추가 코너 케이스를 작성한다.
5. 테스트 양식을 항상 같게 만들 필요는 없다.

볼링 게임 만들기 예.

1. 어떤 객체에 있어야 하는 메서드인지도 정하지 않고, 테스트의 형식을 끄적거려 본다.
2. 대충 UML을 예상해본다. -> 테스트를 거치면서 초기 UML은 별로였다는 걸 깨닫게 된다.
   • 테스트할 객체를 바꾸기도 했다.
3. 코너 케이스가 없는 간단한 테스트부터 시작한다.
   • 기본적인 틀을 잡는다.
   • 실패하는 테스트가 컴파일 되게, return 0을 하는 간단한 함수를 선언한다.
4. 코너 케이스를 추가해본다. (여기서는 스트라이크, 스페어 처리)
   • 중간에 테스트 코드도 리팩터링 한다.
   • 사용하지 않는 메소드는 테스트 코드에서 빼거나, 테스트 코드 자체를 삭제한다.
   • 객체를 추가하는 등 내부 구조를 마음껏 바꾸지만 테스트 코드는 노출된 API와만 관련이 있다.
   • 단일 책임 원칙등은 조금 미뤄두기도 한다.
   • 당장 필요하지 않은 분리를 하거나 객체를 생성하지 않는다.
5. 어떤 함수에 대한 결정 사항이 반복적으로 롤백되기도 한다.
6. 대부분의 코너케이스를 체크하고 통과하고 나서는, 모든 코너를 테스트로 짜본다.
   • 이후 마음껏 리팩토링 한다.
   • 원칙을 생각하며 객체를 구성한다.
   • 이름을 알아보기 쉽게 만든다. 한 줄짜리 코드도 만든다.
   • 필요 없어지는 테스트는 역시 삭제한다.

---

내 생각

마지막의 볼링 점수 예제가 정말 도움이 됐다. TDD와 설계 이론은 알겠는데, 실제 적용은 어떻게 하지? 하는 고민에 적나라하게 답해주는 예다. 책의 뒷부분도 설계 패턴을 설명하기 위해 예제가 많이 들어있는데 따라가면서 읽으면 현재 진행하는 코드의 리팩터링에도 도움이 될 것 같다.

참고

클린 소프트웨어, 로버트 C. 마틴