빌드에 자체테스트를 추가해라. (Make Your Build Self-Testing)

전통적으로 빌드는 컴파일, 링크을 비롯하여 실행 가능한 프로그램을 만들기 위해 필요한 추가적인 모든 작업들을 포함한다. 프로그램이 그냥 구동만 되는 것과 올바르게 작동되는 것은 별개이다. 근래의 정적 타입의 언어들은 많은 버그들을 잡지만, 그것 말고도 더 많은 버그들이 그물을 빠져나간다.

버그를 보다 빨리 효율적으로 잡는 좋은 방법은 빌드프로세스 안에 자동화된 테스트를 포함시키는 것이다. 물론 테스트만으로 완벽한 것은 아니지만, 테스트는 꽤 유용하다고 느낄 만큼 많은 버그들을 추려낸다. 특히 Extreme Programming(XP)와 Test Driven Development (TDD)의 등장으로 자체 테스트(self-testing)는 많이 대중화 되었으며, 그 결과로 많은 이들이 자체 테스트 기법의 효과를 알게 되었다.

내 글의 정기 구독자들은 내가 TDD와 XP의 열혈팬 임을 잘 알고 있을 것이다. 하지만 XP, TDD등 이러한 것들이 자체 테스트의 효과를 내기 위한 필수적인 부분은 아니라고 애기하고 싶다. 두 접근법 모두 코드 작성 이전에 해당 코드가 통과해야 하는 테스트를 먼저 작업하는것을 강조한다. -이러한 상황에서 테스트는 버그잡기 못지않게 설계에 대한 탐색(exploring)에 큰 관심을 기울인다. 이는 좋은 일지만, 자체 테스트에 대해서는 관심이 덜해서 우리가 얘기하는 지속적인 통합의 목적에 필수적이지는 않다.(그럼에도 TDD는 내가 자체 테스트 코드를 작성할 때 선호하는 방법이다.)

자체테스트 코드를 위해 대량의 소스에서 버그를 찾아낼 수 있도록 자동화 테스트 스윗이 필요하다. 테스트는 단순한 명령에서 시작될 수 있어야 하며, 자기 체크(self-checking)가 되어야 한다. 테스트 스위트의 수행결과로, 어떤 테스트가 실패했는지 확인할 수 있어야 한다. 자체 테스트가 수행된 빌드에서 테스트 실패는 빌드 실패로 귀결되어야 한다.

지난 몇년간 TDD의 확산은 이러한 방식의 테스트에 적합한 Xunit들을 유행시켰다. ThoughWorks에서 우리는 XUnit 툴들을 매우 유용하게 사용했고, 나는 항상 다른 사람들에게 이것들을 사용하라고 권장한다. Kent Beck에 의해 소개된 이러한 툴들은 자체테스트 환경구축을 용이하게 해준다.

XUnit툴들은 코드를 자체테스트할 수 있게 해주는 시작점이다. 좀더 end-to-end 테스팅에 촛점이 맞춰진 다른 툴들을 알아볼 필요가 있다. 이 시점에서서  FIT, Selenium, Sahi, Watir, FITnesse 등을 비롯한 다양한 툴들이 있으며, 내가 개괄적으로 리스팅하지 않은 더 많은 툴들이 있다.

물론 테스트로 모든 버그를 찾을 수는 없다.  종종 얘기되는 것처럼 테스트가 버그의 부재를 입증하지는 않는다. 완벽성이 자체테스트 빌드로 얻을 수 있는 것의 유일한 포인트는 아니다. 불완전하지만 자주 수행되는 테스트가 한번도 수행되지 않은 완벽한 테스트보다 훨씬 낫다.

메인글로 돌아가기

원문보기
Continuous Integration

본 포스트는 Martin Fowler 선생께서  쓴 글을 번역 게재한 글이다. 선생은 본인의 글을 직접 게재하는 것을 허용하지는 않지만, 번역은 허용하고 있다.
원문에도 한국어 번역글로 등록이 되어있는데, 이 글보다 몇 년 앞서 더 훌륭한 솜씨로 한글로 번역해 놓은 글이 있으니 참조하면 좋을 듯 하다. (황상철님의 실용주의이야기 의 ‘지속적인 통합‘)

댓글 남기기