『xUnit 테스트 패턴』은 가장 인기 있는 단위 테스트 프레임워크인 xUnit으로 자동 테스트를 작성하는 방법을 완벽하게 지도해준다. 애자일 코치이자 테스트 자동화 전문가인 제라드 메스자로스(Gerard Meszaros)는 테스트 작성, 이해, 유지 보수를 쉽게 해주는 68개의 입증된 패턴을 소개한다. 또한 어떻게 하면 테스트를 더 견고하고 반복 가능하며, 쉽게 만들 수 있는지도 보여준다.

< 소개 >
자동 테스팅(Automated testing)은 애자일 개발의 기초다. 테스팅 전략을 잘 활용하면 기능을 과감하게 추가할 수 있고, 사용자 피드백을 빠르게 받을 수 있으며, 품질을 향상시킬 수 있다. 하지만 많은 개발자가 자동 테스트에 대한 경험이 부족해 효과적인 테스트 작성을 어려워한다.

『xUnit 테스트 패턴』은 가장 인기 있는 단위 테스트 프레임워크인 xUnit으로 자동 테스트를 작성하는 방법을 완벽하게 지도해준다. 애자일 코치이자 테스트 자동화 전문가인 제라드 메스자로스(Gerard Meszaros)는 테스트 작성, 이해, 유지 보수를 쉽게 해주는 68개의 입증된 패턴을 소개한다. 또한 어떻게 하면 테스트를 더 견고하고 반복 가능하며, 쉽게 만들 수 있는지도 보여준다.

★ 이 책에서 다루는 내용 ★
■ 테스트를 더 빠르게, 잘 작성하는 방법
■ 자동 테스트의 4단계: 픽스처 설치, 테스트 대상 시스템 실행, 결과 검증, 픽스처 해체
■ 테스트 스텁(Test Stub)과 모의 객체(Mock Object)로 소프트웨어를 환경으로부터 격리시켜 테스트 커버리지를 향상시키는 방법
■ 테스트하기 좋게 소프트웨어를 설계하는 방법
■ (코드 냄새, 동작 냄새, 프로젝트 냄새를 포함한) 테스트 ‘냄새’로 문제를 파악하고, 이런 냄새를 언제 어떻게 제거할 수 있는지 알아내는 방법
■ 테스트를 리팩토링해 더 단순하고 견고하며 빠르게 실행될 수 있게 만드는 방법

★ 이 책의 대상 독자 ★
개발자, 관리자, 테스터에게 필요한 책이다. 애자일 개발 환경에서 일하느냐, 전통적인 개발 환경에서 일하느냐, 테스트 주도 개발을 하느냐, 테스트 나중 작성을 하느냐는 중요하지 않다. 이 책에서 나온 패턴과 냄새들은 모든 xUnit 계열에 적용할 수 있을 뿐만 아니라 차세대 동작 주도 개발(Behavior-Driven Development) 프레임워크인 RSpect, JBehave뿐만 아니라 기록 테스트 툴이라든지, Fit나 FitNesse 같은 데이터 주도 테스트(Data-Driven Test) 툴에서도 활용할 수 있다.

★ 이 책의 구성 ★
3권의 책을 한 권으로 합쳐 놓은 듯한 방대한 내용으로 구성돼있다.

1부에서는 테스트 전략에서부터 실제 테스트 코딩까지 테스트 자동화에 대한 모든 것을 자세하게 설명한다.

2부에서는 자주 만날 수 있는 18가지 ‘테스트 냄새’ 목록을 보여주고, 문제의 근본 원인과 그에 맞는 가장 적당한 패턴을 찾는 데 도움을 주는 해결 방안을 제공한다.

3부에서는 각 패턴을 자세하게 설명하고, 다양한 프로그래밍 언어로 작성된 예제 코드를 통해 리팩토링하는 방법을 보여준다.

★ 추천의 글 ★
junit.org에 가보면 제가 다음과 같이 써 놓은 글을 볼 수 있습니다. “소프트웨어 개발에 있어 이처럼 많은 사람이 이렇게 적은 코드로부터 이런 큰 도움을 받은 적은 없었다.” 많은 사람이 JUnit을 똑똑한 프로그래머가 일주일이면 만들 수 있는 별 거 아닌 것이라고 혹평해왔습니다. 그런 평가가 사실일지는 몰라도 핵심에는 완전히 벗어나 있습니다. JUnit이 중요하고 처칠의 연설(“인류 분쟁의 영역에 있어 이처럼 많은 사람이 이렇게 적은 사람들에게 이런 큰 도움을 받은 적이 없었다”라는 연설은 처칠이 영국 본토항공전 승리 이후 왕립공군 조종사들의 노고를 치하하며 한 말임 - 옮긴이)을 패러디할 자격이 있는 이유는, 이런 작은 도구 덕분에 수많은 프로그래머에게 테스팅이 프로그래밍의 중심이자 전면으로 떠오를 수 있는 계기가 됐기 때문입니다. 이전에도 이를 주장해 온 사람들이 있었지만 무엇보다도 JUnit이 이런 변화에 가장 크게 기여했습니다.

물론 xUnit은 단순한 JUnit이 아닌 그 이상의 것입니다. JUnit은 수많은 프로그래밍 언어로 포팅됐습니다. xUnit 도구라고 불리기도 하는 일가친척 같은 도구들은 자바라는 뿌리를 넘어 멀리멀리 퍼져나갔습니다(사실 뿌리는 자바가 아닙니다. JUnit보다 몇 년 전에 켄트 벡(Kent Beck)이 스몰토크로 먼저 만들었습니다).

xUnit 툴과 철학은 프로그래밍 팀이 적은 리스크로 코드를 대단위로 수정할 수 있게 도와주는 강력한 회귀 테스트 스위트를 작성할 수 있고, 테스트 주도 개발로 설계 과정을 다시 생각해볼 수 있는 굉장한 기회를 제공합니다.

하지만 이런 기회와 더불어 새로운 문제와 기술도 생겼습니다. 다른 도구처럼 xUnit도 능숙하게 쓰이는 경우도 있지만 서투르게 쓰이기도 합니다. 똑똑한 사람들은 xUnit으로 테스트와 데이터를 효과적으로 조직할 수 있는 여러 방법을 찾아냈습니다. 초창기 객체지향 시대에서처럼 xUnit 도구를 잘 사용할 수 있는 지식 대부분은 숙련된 사람들의 머릿속에만 숨어 있습니다. 이렇게 숨어있는 지식 없이는 xUnit의 혜택을 100% 얻지 못합니다.

객체지향 쪽 사람들이 객체에 이런 문제가 있다는 걸 깨닫고 해답을 찾기 시작한 것이 거의 20년 전입니다. 그 해답은 숨어있는 지식을 패턴 형식으로 작성하는 것이었습니다. 제라드 메스자로스(Gerard Meszaros)는 이런 일을 하는 선구자 중 한 명이었습니다. 제가 처음 패턴을 공부할 때 제라드는 제가 배웠던 리더 중 한 명이었습니다. 패턴 세계에 있는 다른 여러 사람처럼 제라드 역시 익스트림 프로그래밍을 초창기에 도입했고 덕분에 초창기부터 xUnit 도구로 작업해왔습니다. 이러니 제라드가 이런 전문 지식을 패턴 형식으로 기록하는 작업을 맡는 건 당연합니다.

저는 처음 이 프로젝트에 대한 얘기를 듣고 굉장히 들떴습니다(저는 이 책을 저의 마틴 파울러 시리즈에 추가하고 싶었으므로 온갖 수를 다 써서 이 책을 밥 마틴(Bob Martin) 시리즈에서 빼내왔습니다). 다른 좋은 패턴 책과 마찬가지로 이 책은 새로운 사람들에게 이 쪽 분야에 대한 지식을 제공할 뿐만 아니라 경험 많은 전문가가 자신의 지식을 동료들에게 전달하기 위한 용어와 기초를 제공합니다. 유명한 Gang of Four의 책인 『디자인 패턴(Design Patterns)』은 많은 사람에게 객체지향 설계의 숨어있는 보물상자를 열어줬습니다. 이 책은 xUnit에 있어 그런 역할을 할 것입니다.

마틴 파울러
ThoughtWorks의 수석 과학자이자 마틴 파울러 시리즈 에디터

★ 옮긴이의 말 ★
어느덧 ‘단위 테스트’라는 단어는 개발자들 사이에서 익숙해졌습니다. 팀에 적용하고 있다는 분들도 많더군요. JUnit은 4.8까지 나왔고, 구글에서도 GoogleTest 같은 프로젝트가 나왔습니다. CruiseControl이나 Hudson 같은 CI(Continuous Integration) 툴에 단위 테스트를 붙여 지속적인 통합을 하는 팀뿐만 아니라, 단위 테스트 코드 커버리지 90% 이상 달성을 KPI로 잡는 개발 팀도 있다고 들었습니다.

이렇게 단위 테스트가 많이 전파된 것처럼 보이지만 막상 개발자들 얘기를 들어보면 고민이 많습니다. “제대로 된 책도 별로 없고, 모의 객체(Mock Object)를 어떻게 설정해야 하는지 잘 모르겠고, 함수 하나만 고쳐도 컴파일 에러가 너무 많이 나서 개발에 거치적거리는 것만 같고, 관리자는 그런 거 왜 하냐고 무시하기나 하고, 에이, 그냥 하지 말까?”

리니지2 개발 팀에서는 2007년 4월부터 단위 테스트(UnitTest++)를 도입했습니다. 처음부터 쉬웠던 건 아닙니다. 코드 여기저기를 #ifdef USING_TDD로 감싸줬음에도 불구하고 테스트 대상 시스템(SUT, system unter test) 코드를 잘못 건드리는 바람에 오히려 없던 버그를 만들기도 하고, if (g_bTesting) 같은 테스트 훅(Test Hook)을 잘못 넣거나, 공유 픽스처(Shared Fixture)를 제대로 해체(Teardown)하지 않아서 다른 팀원들까지 많이 고생시켰습니다.

하지만 많은 분께서 도와주신 덕분에 단위 테스트는 점차 안정되어 갔습니다. 2007년에 200여 개였던 단위 테스트는 2009년에는 1,300개 이상으로 늘었습니다. 단위 테스트가 실패하면 개발 팀 전원에게 이메일을 보내 왜 테스트가 깨졌는지를 모두가 공유하고 도와줄 수 있게 했습니다. 덕분에 나중에는 기획 팀과 함께 단위 테스트 코드를 보면서 기능이 수정될 때 결과가 어떨지를 바로 확인할 수 있었고, 훨씬 편안한 마음으로 리팩토링하고 새로운 기능을 빠르게 추가할 수 있었습니다. KGC(Korea Games Conference) 2008 강연을 준비하면서 단위 테스트가 팀의 개발에 어떤 도움을 주었는지를 보기 위해 버그 트래커 자료를 기반으로 개발 기간 동안 발생한 버그 개수와 에러 수정에 걸리는 시간을 팀 전체와 단위 테스트가 적용된 파트로 나눠 조사해봤습니다. 그 결과 단위 테스트 개수가 늘어날수록 버그 발생 비율이 낮아지고, 버그 수정 속도도 최대 2배 이상 빨라졌음을 알 수 있었습니다(관련 자료: http://parkpd.egloos. com/1944077).

이 책 『xUnit 테스트 패턴』에는 단위 테스트에 대한 거의 모든 정보가 들어 있습니다. ‘이 책을 1~2년만 더 빨리 읽었더라면 삽질을 덜 했을 텐데’ 하는 생각에 아쉬움도 들더군요. ‘우리 프로젝트에서는 어떻게 적용해볼 수 있을까’를 생각하면서 읽으면 더 재미있게 보실 수 있습니다. 이해가 잘 안 될 때는 예제 코드를 먼저 보세요. 때로는 천마디 글보다 한 줄의 코드가 더 이해하기 쉬울 때가 있으니까요.