옮긴이의 말

“제품설계가 요구사항에 달아 소스코드로 서로 사맛디 아니할쌔
이런 전차로 어린 개발자가 검증하고저 홇배 이셔도
마침내 제 뜨들 시러 펴디 몯홇 하니라.
내 이랄 윙하야 어엿비 너겨 새로 책 한 권을 번역하노니
사람마다 해여 수비니겨 날로 쑤메 뼌한키 하고져 할 따라미니라.”

처음 이 책을 접했을 때 가장 먼저 눈길을 사로잡았던 것은 바로 『Effective Unit Testing』이라는 책의 제목과 테스트 가능 설계testable design라는 7장의 제목이었다.
과연 Effective라는 이름을 내걸기에 부끄럽지 않은 책일까? Effective로 시작하는 책 대부분은 유행에 흔들리지 않고 비교적 오랫동안 가치를 인정받는 듬직함을 보여준다. 단순한 따라하기나 기교 중심의 어떻게(how)가 아닌, 주제에 관한 깊은 이해와 오랜 경험으로부터 우러나온 왜(why)를 다루기 때문이다. 왜를 이해한다는 것은 명확한 목적의식을 가지고 행동하게 되며, 변화하는 환경에서도 흔들리지 않는 근본적인 기준에 따라 판단하고 응용할 수 있게 됨을 의미한다. 이러한 관점에서 이 책은 전혀 부족하지 않다고 판단되었고 번역 제안을 수락한 결정적인 이유가 되었다.
개인적으로는 2006년경에 테스트 가능 설계 안티 패턴을 정리하려던 적이 있었다. 홀대받는 테스트가 사실은 제품 설계와 생산성에 큰 영향을 주므로 개발 초기부터 이를 고려하면 전반적인 개발 과정이 훨씬 효율적이고 부드럽게 진행된다는 점을 알리고 싶었다. 당시만 해도 개척할 게 많은 분야였던 터라 잘 다듬어서 저널이나 학술지에 내볼 요량이었다. 하지만 컨설턴트도 아니고 테스트가 주업도 아닌지라 원하는 만큼의 적절한 예제를 모으는 데 한계가 있었고, 결국 어설픈 초안 수준에서 그만두고 말았다. 이러한 개인적 경험 때문에 테스트 가능 설계란 주제는 큰 호기심과 아쉬운 감정을 동시에 불러일으켰다. 그래서 이 책을 통해 내가 정리하던 것과 얼마나 유사한지, 혹은 더 발전했는지 확인해보고 싶었다. 결국, 구성이나 내용 면에서는 많은 차이를 보였지만 큰 그림과 의도는 일맥상통했다. 그래서 이렇게 다른 이의 결실에 편승해서라도 그때 하고자 했던 이야기를 세상에 들려주고 싶다는 동기가 더해졌다.

“좋은 설계임을 증명하려거든 자동화된 테스트를 만들어보라!”

흔히 실력 좋다고 알려진 개발자 중 많은 수가 무척 복잡하여 어떻게 쓰는지 모르겠는 코드를 내놓거나 겉은 깔끔하나 그 정도가 지나쳐서 내부 동작원리는 알기 어려운 코드를 만들어내곤 한다. 이런 코드는 검증하기 어렵다는 치명적인 단점이 있다. 개발자 자신이 시연할 때에는 잘 돌겠지만 다른 모듈과 통합할 시점이 되면, 혹은 제품이 출시된 후 소비자에 의해 다양한 패턴으로 사용되면서 뒤늦게 문제가 하나씩 터져 나오는 경우가 많다. 단기간에 가시적 결과를 보여줄 수는 있지만 이렇게 발견된 문제는 개발한 당사자가 아니면 쉽게 손대지 못하니 골치 아픈 상황을 낳기도 한다. 이들의 능력을 깎아 내리려는 의도는 절대 아니다. 다만, 한 차원 높은 생산성과 안정된 품질, 그리고 동료 개발자도 쉽게 이해하고 배울 수 있는 코드를 작성하는 쉬운 방법이 있으나 잘 알지 못하는 듯하여 안타까울 뿐이다.
그들에게 필요한 것은 테스트에 대한 인식 전환이다. 테스트란 단순한 기능 검증 수단만이 아닌 요구사항을 명시한 문장이요, 모듈과 API 설계 수단이며, 사용설명서이자, 최고의 인수인계/유지보수 자료이기까지 하다. 특히 개발자의 설계역량 면에서 본다면, 디자인 패턴에만 의지하기보다 테스트하기 쉬운 설계를 추구하는 쪽이 훨씬 탄탄한 기본기와 응용력을 길러줄 것이라고 감히 단언할 수 있다. 여러분이 이 책을 테스트 지침서가 아닌 설계 지침서로 받아들이고 잘 따라준다면 어느덧 진일보한 자신의 실력에 놀라게 될 것이다.
아무쪼록 독자 여러분께 재미나고 유익한 책이 되길 기원하며, 책 내용 중 혹 궁금한 것이 있거든 wegra.eut@gmail.com으로 물어봐 주시길 바란다. 여건이 허락하는 한 성심껏 답변하도록 노력하겠다.

옮긴이_이복연

지은이의 말

2009년 6월 10일 밤, 매닝Manning의 크리스티나 러들로프Christina Rudloff로부터 한 통의 메일을 받았다. 그녀는 로이 오쉐로브Roy Osherove의 저서 『The Art of Unit Testing in .NET』을 자바에 맞게 다시 써줄 만한 사람을 찾고 있었다. 기꺼이 내가 해주겠노라 답했다.
이건 꽤 오래 전의 이야기로, 지금 여러분의 손에 들려 있는 이 책은 로이의 것과는 사뭇 다른 모습이 되었다. 설명을 해보자면 이렇다.
처음에는 .NET을 자바로 단순 변환하는 일로 시작했다. 달라진 플랫폼과 도구만 반영하고 독자에게 꼭 필요한 부분만 다시 쓰면서 말이다. 1장을 마치고 2장을 마치고 3장까지 써내려 가다가 문득 하나를 깨달았다. 문장 몇 개 정도가 아니라 한 장chapter 전체를 내가 새로 쓰고 있는 게 아닌가? 문체도 나와 맞지 않았다. 로이와는 다른 방식을 선호하거나 그의 설명에 동의하지 못할 때도 종종 있었다. 여러분에게 따로 꼭 하고 싶은 말이 있거나, 설명을 보충하거나, 기초부터 확실히 다지고 넘어가고 싶다는 욕심이 강하게 생겨나기도 했다.
결국, 처음부터 새로 시작하기로 했다. 처음 의도했던, 자바 버전에 맞게 쓰는 일을 넘어선 시점이었다. 좋은 테스트를 작성하는 방법과 주의 사항에 관한 심도 있는 통찰을 통해 자바 프로그래머의 테스트 능력을 키워주는 새롭고 독특한 책으로 거듭난 것이다. 로이의 생각도 다양한 형태로 이 책에 스며있다. 예컨대 2부를 구성하는 4, 5, 6장의 이름은 로이의 것을 고스란히 차용했고, 7장도 상당 부분은 로이의 책 『The Art of Unit Testing in.NET』의 관련 내용에 기초하여 썼다.
이 책은 자바 개발자를 위해 쓰였지만, 독자 범위를 인위적으로 제한하고 싶지는 않았다. 비록 2부의 예제 코드는 모두 자바지만, 내용 자체는 언어에 너무 국한되지 않게 하려 노력했다. 좋은 테스트를 작성하는 방법은 언어와 무관하니 설령 여러분의 주 언어가 자바가 아니더라도 이 책의 내용을 진지하게 읽어보기를 진심으로 권한다.
같은 맥락에서, 이 책을 JUnit 또는 개인적으로 선호하는 특정 Mock 객체 라이브러리를 배우기 위한 튜토리얼로 만들고 싶지 않았다. 시시때때로 변하는 기술, 또는 출판 후 몇 달이면 폐기될 지식은 배제하고, 나 자신이 정말 읽고 싶은 책을 쓰고 싶었다. 눈 감고도 사용할 만큼 이미 익숙해져 버린 테스트 프레임워크나 쓰지도 않는 Mock 객체 라이브러리를 억지로 들이대지 않는 그런 책 말이다. 그래서 특정 기술에 종속된 조언은 최대한 자제하였다. 물론 전혀 없다고 말할 순 없지만, 최선을 다했음을 알아줬으면 한다. 테스트 작성과 실행, 유지보수, 개선에 빠져서는 안 될 기본적인 개념과 의미 있는 논의가 필요한 정도만을 담아내었다.
다시 한번 말하지만, 나 자신이 읽고 싶은 책을 쓰려고 노력했다. 여러분도 함께 즐겨주길 바라고, 무엇보다 책 내용 중 일부라도 실천하는 독자가 나와준다면 더 바랄 것이 없다.

지은이_ 라쎄 코스켈라

테스트 라이브러리 사용법에서 나아가 ‘좋은 테스트란 무엇인가’, ‘좋은 테스트를 작성하려면 어떻게 해야 하는가’에 관한 현장의 물음에 해답을 제시한다.<br/><br/><b>이 책의 특징과 장점 </b><br/>테스트가 갖춰야 할 요건에 따라 나눈 테스트 카탈로그를 제공한다. 따라서 필요할 때마다 원하는 목록을 참고하여 자신이 작성한 테스트에서 문제를 발견하고 수정해 나갈 수 있으며 더욱 응용력 높은 학습을 할 수 있다. <br/><br/><b> 어떤 독자를 위한 책인가? </b><br/>-. 테스팅 경험은 있으나 테스트의 품질을 자신할 수 없는 자바 개발자<br/>-. 테스팅에 대한 개념이 아직 명확하지 않은 사람<br/>-. QA 부서에서 직무 교육을 받는 테스터/개발자