실용주의이야기(Pragmatic Story)

이 기사는 마틴파울러의 Continuous Integration을 번역한 기사임을 미리 밝혀둡니다.

셀프 테스팅 빌드 만들기

보통 빌드는 컴파일, 링킹외에 프로그램을 실행하는데 필요한 모든 자질 구레한 일을 의미한다. 프로그램이 실행된다고 해서 아무런 문제가 없다고 할수는 없다. 요즘 언어들은 많은 버그를 잡을수 있지만 놓칠수도 있다.

버그를 더 빨리 효율적으로 잡는 좋은 방법은 빌드 프로세스에 자동화된 테스트를 추가하는 것이다. 물론 완벽한 테스트는 없다. 하지만 사용하기 충분할 정도의 많은 버그를 잡을수 있다. 특히 XP와 TDD가 등장 하면서 셀프 테스트 코드가 인기를 끌게 되었고 그 결과 많은 사람들이 이 기법의 가치를 알게 되었다.

내 글을 읽는 독자들은 내가 XP와 TDD를 광적으로 좋아한다는걸 알고 있을것이다. 그러나 나는 이런 접근이 셀프 테스트 코드의 이점을 얻는데 꼭 필요한건 아니라는 점을 강조하고 싶다. 이 접근방법 둘다는 코드를 작성하기 전에 작성한 테스트 코드가 패스하는것을 중요하게 여긴다. 이런 테스트는 버그를 잡을수 있는 시스템을 설계하게 해준다. 이는 좋은일이지만 CI에서 반드시 필요한건 아니다. 셀프 테스트 코드에 대한 요구는 약한 편이다.(TDD는 셀프 테스트 코드를 만드는걸 선호하는 편이다.)

셀프 테스트 코드에서 자동화된 테스트는 버그를 담고 있는 코드의 많은 부분을 검사할수 있어야 한다. 테스트는 간단한 명령어를 실행하는일을 없애주고 스스로를 체크할수 있어야 한다. 테스트를 실행한 결과는 어떤 테스트든지 실패하게 되면 이를 알아 차릴수 있게 해주어야 한다. 빌드 하는 동안에 셀프 테스팅이 실패하면 빌드는 실패하게 된다.

최근 몇년간에 걸쳐 TDD의 증가는 이런 종류의 테스트에 적합한 XUnit 계열의 오픈소스툴을 인기 상승을 가져왔다. XUnit 툴은 우리 ThoughtWorks사에게 매우 가치가 있다는것이 증명되었고 나는 항상 사람들에게 이를 사용하라고 제안하고 있다. 이 툴은 켄트벡(Kent Beck)에 의해 시작되었으며 셀프 테스팅 환경을 구성하는것을 도와준다.

XUnit 툴이 셀프 테스팅 코드를 만들기 위한 시작점이라는 것은 확실하다. 엔드 투 엔드(end-to-end) 테스팅을 위한 다른 툴을 찾을수 있는데   FIT, Selenium, Sahi, Watir, FITnesse가 바로 이런 툴로서 아주 넓은 범위의 테스트를 위한 툴인데 여기서이 툴에 대해 상세하게다루지는 않겠다.

물론 버그을 찾기위해 테스트에만 의지할 수는 없다. 테스트는 버그가 없다는 사실을 증명해주지 못한다. 그러나 셀프 테스팅 빌드가 도움이 된다는것은 확실하다. 완벽하지 못한 테스트라도 자주 실행하는게 완벽한 테스트를 전혀 작성하지 않은 것보다는 낫다고 할수 있다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.