회사 프로젝트에서 유닛테스트를 만들기 시작한지는 일년쯤된 것 같다.
그동안 개발팀원들은 테스트환경을 꾸준히 개선 했다.
몇가지 중요한 이슈를 정리하자면,
- 싱글턴과 전역변수의 형태로 존재하는 전역객체들을 랩핑하여, 테스트 슈트(test suit)에서 바꿔칠 수 있게 됐다.
- 부가적으로 필요한 기능들은 전부 UnittestHelper 클래스로 몰아넣어 편의를 도왔다.
- 네트워크 패킷을 가상으로 주고 받을 수 있다.
- 범용적인 Mock 클래스들을 정리해두었다.
이러한 노력의 결실들로 테스트코드는 매우 생산적으로 만들어낼 수 있게 되었지만 여전히 내가 작성한 테스트의 커버레이지는 한계가 있었다.
도입 초기에 내가 테스트코드를 만드는 목적은 어디까지나 로직을 완전히 개발한 후, 보수하는 차원에서의 역할에 만족하고 있었다.
어설프게라도 테스트코드를 손에 넣고나면 마음은 든든하고 안정적이었지만, 어디까지나 보조적이라는 생각을 갖고 있던 나에게는 거기에 드는 정신적인 비용이 너무나도 컸다.
그러던 어느날 구글이 크롬을 발표했다. 크롬이야 지금도 매우 유용하게 쓰고 있는 웹브라우저이지만 그것보다 그들이 크롬을 오픈소스로써 발표했다는데 더 큰 의미가 있었다.
제대로 된 테스팅 프로젝트를 본적이 없는 나에게 크롬의 테스트코드는 문화적 충격이었다.
그들은 너무하다싶을정도로 철저히 테스트코드를 만들어 테스트 커버레이지를 완벽에 가깝게 추구하고 있었다. 그리고 그들은 테스트코드를 명확하고 간결하게 유지하고 있었다.
테스트코드가 유연하기 위해서는 항상 개선되야 하기때문에 간결함은 필수불가결한 요소라는 생각도 들었다.
크롬소스를 본 후, 테스트코드의 커버레이지를 높히려고 노력하다보니 어느새 테스트코드는 로직의 일부처럼 다루게 되었다.
더 나아가 모든 로직의 중요한 부분을 테스트코드를 선행해서 만드는게 유리하다는걸 체감하게 되었다.
테스트코드를 로직개발 이후에 만들게 되면, 로직의 중요한 굴곡에 테스트코드를 배치할 가능성이 낮아진다.
테스트코드를 선행하고 실패한 것을 확인하고 로직을 개발하게 되는게 프로세스로 정립되면, 로직의 각 중요한 요소 모두에 테스트코드가 배치되게 된다.
이러한 TDD(Test-Driven Development)방식의 개발은 테스트하고자 하는 모듈의 입력 인터페이스에 매우 의존적이게 된다. 로직 개발 초기에는 큰 변화가 필연적으로 많을 수밖에 없고, 변화가 테스트코드의 입력부부터 영향을 주게 된다. 따라서 입력부가 최대한 캡슐화되고 다른 모듈과 결합되어있지 않을수록 유리하다.
그래서 네트워크 패킷으로 로직의 진입점이 될 수있는 것은 최대한 패킷 핸들링 단위부터 테스팅이 되도록 유도했다.
다행히도 네트워크 패킷을 가상으로 주고 받는 기능이 잘 만들어져있어 그러한 작업은 수월하게 진행할 수 있었다.
지금와서 회상해보면, 유닛테스트를 처음 도입할때는 비용이 크다. 그 비용은 프로젝트 진척도에 비례한다.
유닛테스팅의 기반 환경을 만들기까지의 비용이 많이 들고 개발 패러다임이 바뀌는만큼 적응에 적지 않은 시간이 요구된다.
하지만, 일단 개발 프로세스로 정착되고나면 개발의 속도는 점점 가속되고 기능의 안전성을 높은 쿼리티를 유지할 수 있게 된다.
이제는 유닛테스팅 없는 개발은 상상하기 힘들고, 그런 암흑기는 생각하기조차 싫다. -_-;
(0) 
(0)"일반" 카테고리의 다른 글
- 유닛테스트를 해보고 느낀점 (8)2008/09/23
- 미리 컴파일된 헤더 쓸때 종종 나오는 경고 (C4727) (1)2008/01/07
Posted by Mizelan
