JUnit

마이크로소프트웨어 2006년 9월호에 기고했던 글입니다.

테스트는 사용자의 요구사항을 만족하는 고품질의 소프트웨어를 얻기 위한 소프트웨어 개발 과정의 가장 핵심적인 구성 요소이다. 테스트를 통해 수렴된 요구 사항을 만족하는지에 대한 검증(Verification)과 그 문제를 해결하는 과정이 우리가 의도한 대로 동작하고 있는지에 대한 검사(Validation)가 이뤄지기 때문이다. 다양한 테스트 기법 중에서도 가장 기본이 되는 것이 바로 단위 테스트이다. 단위 테스트는 소프트웨어의 가장 기본이 되는 단위, 즉 클래스를 대상으로 하며 테스트 대상이 되는 클래스 내부를 알고 있는 개발자에 의해 직접 테스트가 이뤄지기 때문에 화이트 박스(White Box) 테스트, 또는 개발자 테스트라고 불리기도 한다. 시스템의 품질을 유지하기 위해 테스트가 가지는 중요성을 알기 때문에 대부분의 프로젝트 팀에서는 QA팀이나 전문 테스터를 확보하고, 테스트 커버리지 툴을 비롯한 다양한 도구를 활용하고 있지만, 개발자에 의해 작성된 코드 자체가 버그를 갖고 있다면 성능 테스트나 통합 테스트의 결과 역시 신뢰할 수 없다. 이러한 이유로 단위 테스트는 모든 테스트 활동의 기반이 되는 출발점이라고 볼 수 있다.

이 책은 실용주의 프로그래머를 위한 시리즈 중 두 번째 책으로 단위 테스트의 기본이 되는 JUnit을 다룬다. 단순히 JUnit을 사용하는 방법에서 그치는 것이 아니라, 왜 단위 테스트를 수행해야 하며 무엇을 테스트 해야 하는지 또한 보다 효과적인 실천 방법이 무엇인지에 대해서도 소개하고 있기 때문에 단위 테스트를 배우고자 하는 초급자나 바쁜 시간을 쪼개어 테스트를 작성해야 하는데 불만을 품고 있는 개발자들에게 훌륭한 지침서가 되어줄 것이다. 그러나 이 책을 읽고 따라 하는 것만으로 실전에서 테스트를 잘 작성할 수 있으리라는 기대는 하지 않는 것이 좋다. 테스트를 잘 작성하기 위해서는 생각보다 훨씬 더 많은 경험과 훈련을 필요로 하기 때문이다. 한꺼번에 모든 것을 익히고 실천하기 어렵다면 최소한 “1일 1테스트“부터 시작해보자. 6개월 이상을 꾸준히 연습하다 보면 테스트 없이 그동안 어떻게 개발 업무를 진행해 왔는지를 스스로 신기해하는 날이 여러분에게도 찾아오게 될 것이다.

테스트에서 2가지 강조하고 싶은 점은 TDD와 자동화된 테스트이다. 완성된 것처럼 보이는 복잡한 로직을 눈 앞에 두고 거꾸로 테스트 코드를 작성하는 것은 겪어본 사람만이 알 수 있는 고통이다. 테스트가 필수적인 개발 활동이라는 인식에 대해 공감한다면, 반드시 테스트 주도 개발방법을 익히도록 하자. 인터페이스 중심 설계, Mock/Stub의 활용, EasyMock 과 같은 라이브러리 사용법, 코드리뷰와 리팩토링, 짝 프로그래밍 등은 여러분이 테스트 주도 개발방법을 익히는데 큰 도움을 줄 수 있는 대표적인 기법들이다. 또 한 가지는 모든 테스트를 자동화하라는 것이다. 특히 권장할 만한 것은 Cruise Control 등의 도구를 활용한 지속적인 통합(Continuous Integration)이다. 필자가 진행하는 프로젝트에서는 매일 2시간 간격으로 테스트가 자동으로 수행되어, 그 결과가 보고된다. Clover와 같은 테스트 커버리지 도구의 활용도 적극 추천한다. 자신의 모든 코드가 100% 테스트되었다는 자신감은 여러분을 한 층 더 높은 수준의 개발로 인도해줄 것이다.

어떤 좋은 도구나 기법을 활용하더라도 잘 훈련된 개발자 없이는 원하는 결과를 얻지 못한다. 스스로 만족할 수 있는 단순하고 명확한 코드에 욕심을 내는 개발자라면, 이 책을 통해 테스트 능력을 배양하는 것이 그 목표에 도달할 수 있게 하는 지름길이 되리라는 것을 감히 얘기해본다.