테스트 주도: (1) 기능 구현 위주로 생각하지 않기

경험을 위주로 작성하는 것이므로 많이 보는 텍스트에서 강조하는 것을 간과할 수도있고, 없는 것도 있을 수 있는 글이 될 것 같다.


테스트 주도형 개발의 가장 기본적인 개념은 테스트 코드를 먼저 작성하고 그 코드가 돌아 갈 수 있는 함수를 만든다는 것이다. 이것만으로도 기존의 습관을 버릴 수 있는 생각의 사유가 되나 전통적인 방식(설계->구현->테스트)의 개발에 익숙한 사람이 쉽사리 옮겨가지 못하는 것은 시간에 대한 두려움이 있기 때문이다.


누구나 다 아는 사실은 테스트 코드를 먼저 작성하여 버그를 줄이는 것이 오히려 전체 시간을 줄일 수 있다는 것인데 그것은 습관적으로 진행되는 것에 의한 관성이 너무도 크기 때문에 쉽게 체득되지 않는 다. 완벽히 XP 방식의 테스트 주도형 개발을 진행하는 것이 어렵다면 조금씩 고쳐나가는 것이 어떤가. 앞으로, 개발 방법을 바꿔가는 것에 대한 어중간한 상태를 인정하고 유용하다 생각되는 기술을 습득하는 방법을 얘기해보고자한다. 설계가 완벽하게 된 후 개발이 진행되었건 조금씩 살을 붙여가며 살아 있는 듯 진행되었건 멋있는 코드는 멋있기 마련이다.


기능 구현 위주로 생각하는 습관을 버린다는 것은 기능 외의 것을 꼼꼼히 챙겨서 처리한다는 것이다. 설계와 구현을 다른 사람이 한다고 하면, 기능이 주어졌을 때, 설계시에 그것이 정상적으로 동작하는 경로에 대한 것은 명확하지만, 아주 세세한 부분까지 설계 문서에 넣기에는 사실 시간상 어려운 부분도 있고, 지루한 반복이 생길 수도 있으므로, 흔한 예외는 구현하는 사람의 역량에 맡겨지는 경우가 대부분이다.


이제 말하는 몇가지 요점들에서 언급하는 "테스트 케이스"라는 것은 테스터가 작성하는 테스트 코드에 도움을 줄 수 있는 정도를 말하는 것이지 테스터를 위한 것이 아니다. 그리고 개발자가 해야 하는 최소한의 동작 방식에 대한 모듈 테스트 코드를 만드는데 필요한 것들을 일컫는다.


기능 구현위주를 탈피하기 위해서는 다음과 같은 사항을 꼼꼼히 봐야한다.

1. 에러확인 API가 따로 존재하나?
커널 관련해서는 errno 변수가 있고, 정규식의 경우 regerror 함수가 있는 것처럼 에러처리 함수를 적절히 만들어야 한다. 그렇지 않으면, 에러 조건이 명확하게 되지 않으며, 이는 테스트 목록이 부실해지는 결과가 되고 나아가 에러로그가 없으므로 테스트 할 수가 없게되는 상황이 발생할 수도 있다.

2. 사용하는 라이브러리가 여러 개일 경우 발생하는 에러들이 적절하게 통합되는가?
사용하는 라이브러리가 오류를 일으킬 경우, 로그를 바로 남길 수도 있고 그 치명도에 따라서 위로 보고할 경우 통합하여 보고할 수도 있다. 이런 것이 없는 설계에서는 테스트 케이스를 만들 때에 예상되는 오류를 만드는데 문제가 생길 수 도 있으며, 정작 오류가 발생할 때 정확한 로그가 없어 해결 할 수 없는 상황이 발생하기도 한다.

3. 클래스를 사용하는 경우 발생하는 예외에 대한 적절한 처리를 하고 있는가?
문서상에 존재하는 모든 예외를 테스트한다고 가정하고 이를 적절히 처리해야 한다.

4. 치명적인 에러 처리 경로와 무시할수 있는 에러를 적절히 처리하는가?

치명적인 에러와 무시할 수 있는 에러는 프로세스가 종료되어야하는지 여부와 관련되어 있다. 치명도에 따라서 테스트하는 것은 아니지만, 무시할 수 있는 에러들을 이어서 테스트 하고, 치명적인 것들은 따로 모아서 테스트하게 될 경우 테스트 설계에 유용한 정보가 될 수 있다.

테스트 주도형 개발을 하게 되면 코드끼리 대화한다. 테스트 코드는 주 코드를 테스트하고 주 코드는 테스트 코드를 테스트 한다. 서로가 서로에게 동작을 보증해주는 방식으로 설계된다. 둘다 예외에 대한 대화 루트가 명쾌해야한다.