단위 테스트 코드 작성을 기본으로 하는 테스트 주도 개발 방식은 소프트웨어가 테스트 가능한(Testable) 구조를 갖도록 강제하며, 이로 인해 보다 간단하면서도 구조화된 설계로 이끌 뿐만 아니라 코드에 대한 신뢰를 높일 수 있는 효과적인 방법이다. 이 책에서는 Go, 자바스크립트, 파이썬의 세 가지 프로그래밍 언어로 테스트 주도 개발을 실천하는 실용적 방법을 제공한다. 켄트 벡(Kent Beck)의 저서 『테스트 주도 개발』(인사이트, 2014)에서 다룬 돈 문제(Money Problem) 예제를 각 언어로 재해석해 서술했으며, 테스트 주도 개발 방식에 쉽고 재미있게 익숙해질 수 있도록 돕는다. 실패하는 테스트를 먼저 작성하고 프로덕션 코드를 작성해 테스트를 통과하게 만든 후 개선하는, '레드-그린-리펙터 사이클'의 테스트 주도 개발 필수 구성 요소 세 단계를 다룬다. 또한 GitHub Action을 활용한 지속적 통합과, 자동화된 회귀 테스트의 실천적 방법을 제시한다.

컴퓨터과학 및 소프트웨어 공학 교육자로 일한 30년 경력을 통틀어, 2001년 산업계에 잠깐 몸담은 이후로 자동화된 단위 테스트만큼 내 수업과 연구를 형성하고 스며든 기술은 거의 없었다. 테스트 주도 개발(Test-Driven Development, TDD)은 구체적이지만 널리 적용 가능한 기술로 운용할 수 있는 일반적인 접근 방법이다.
마틴 파울러(Martin Fowler)의 『UML Distilled』(홍릉과학출판사, 2005)를 객체지향 개발 수업교재로 채택한 후, 여전히 테스트 주도 개발을 구체적인 의미에서 대부분을 부작용으로 이해한 기억이 난다. 마틴은 성공적인 반복 개발 프로세스에서 주로 발견되는 세 가지 주요 사례인 자동화된 회귀 테스트, 리팩터링, 지속적 통합을 논의한다. 이 간단 명료한 설명이 뇌리에 박혀, 가르치는 입장에서 학생들이 코드의 나머지를 테스트할 추가적인 코드를 작성할 때 다채로운 테스트 결과의 형태로 즉각적인 피드백이 이뤄지도록 설득하는 과정이 늘 즐거웠다.
깨달음의 순간은 거의 10년이 지난 2012년경에 또 있었다. 소프트웨어 아키텍처에 관한 소프트웨어 엔지니어링 라디오 팟캐스트를 듣기 시작할 때였다. 팟캐스트에서 언급된 참고 문헌을 읽다가 ‘밥 삼촌(Uncle Bob)’ 로버트 C. 마틴(Robert C. Martin)의 저서 『클린 소프트웨어』(제이펍, 2017)에서 ‘뜻밖의 재미있는 아키텍처’란 제목의 짧은 절을 우연히 발견했다. 이 절에서는 테스트 가능한 코드를 만드는 데 집중하는 것이 어떻게 관리 가능한 아키텍처라는 좋은 방향으로 대부분 자연스레 이어지는지 논의한다.
두 가지를 종합하면 자동화된 테스트가 프로세스와 아키텍처뿐만 아니라 기능 및 비기능 요구 사항을 함께 묶는 방법이라 강조한다. 코드가 기능 요구 사항을 충족시키는 데 더 많은 신뢰를 줌으로써, 테스트 가능성(Testability)은 거의 틀림없이 가장 중요한 비기능 요구 사항이 된다.
거의 10년이 지난 해 여름, 저자로부터 그의 책에 관해 연락을 받았다. 덧붙여 말하자면, 내년은 저자와 함께 세 개의 대학원 과정 수업을 수강한 지 25주년이 되는 해다! 그가 성공적인 기술 전문가이자 마틴 파울러와 같은 사상가, 저자가 되는 걸 보는 것은 매우 보람된 일이다. 테스트 주도 개발을 늘 더 배우려는 열정이 있는 저자에게 추천사를 부탁받아 영광이라 생각했다.
특히 이 책에는 일상 생활에서 매우 익숙한 실행 예제를 사용해 직접 해보면서도 체계적인 방식으로 테스트 주도 개발 프로세스에 독자의 마음을 사로잡는 점이 담겨 있어 매우 인상적이다. 레드-그린-리팩터 사이클은 프로그래밍 언어에 관계없이 프로세스의 분위기를 설정한다. 금융 통화 도메인에서 계속되는 피처는 구체적이고 관련시키기 쉽지만, 계속해서 더 복잡한 문제 사이로 독자를 안내함으로써 신뢰를 구축하고 미묘한 타협점을 노출시키고, 나아가 탐구하려는 호기심을 일깨운다. 최종 코드 리뷰는 프로필, 목적, 프로세스의 세 가지 관점으로 검토하며 그 과정에서 수집된 통찰력을 통합시킨다.
약간 상호 보완적인 설계를 바탕으로 Go, 자바스크립트, 파이썬이라는 인기 있는 언어로 테스트 주도 개발 접근 방식의 광범위한 적용 가능성이 있는 강력한 사례를 글로 녹여 냈다. 자바스크립트와 파이썬은 이미 시장에서 최고 위치를 차지하고 있으며 Go는 빠르게 떠오르고 있다. 뿐만 아니라 언어 설계와 세 개의 프로그래밍 언어 간 관계의 인식과 부가적인 접점을 제공한다.
Go, 자바스크립트, 파이썬과 같이 영향력이 강한 언어에 끌린 새로운 소프트웨어 개발자 세대와 함께 공명해 상승 효과를 내고 테스트 주도 개발의 고결한 길을 이끌어 낼 책이길 바란다. 최고의 재즈 색소폰 연주자인 캐넌볼 애덜리(Cannonball Adderley)가 뉴욕에서 실시간 관람 중인 청중에게 ‘힙하다(Hipness)’를 설명할 때 했던 말을 빌려 글을 마무리하겠다.
‘힙하다’는 것은 마음 상태가 아니라 피할 수 없는 인생의 현실이다!

―콘스탄틴 로이퍼(Konstantin Läufer),
로욜라 대학교 시카고 컴퓨터과학과 교수

◆ 도메인 복잡성을 제어하기 위한 테스트 주도 개발의 분할 정복 접근 방법 사용
◆ 언어, 테스팅 프레임워크, 도메인 개념을 아우르는 테스트 주도 개발 동작 방식 이해
◆ 테스트 주도 개발이 지속적 통합을 가능하게 하는 방식 학습
◆ 테스트 주도 개발을 바탕으로 리펙터링 및 재설계 지원
◆ 자바스크립트로 간단하고 효과적인 단위 테스트 하네스 작성 방법 학습
◆ 테스트 주도 개발 진행 중 만든 단위 테스트를 바탕으로 지속적 통합 환경 구축
◆ 테스트 주도 개발을 사용해 Go, 자바스크립트, 파이썬으로 깨끗하고, 깔끔한 코드 작성

소프트웨어를 작성하는 개발자를 대상으로 한다.
‘개발자’에 어울리는 직함이 많다. 소프트웨어 엔지니어, 애플리케이션 아키텍트, 데브옵스 엔지니어, 자동화 테스트 엔지니어, 프로그래머, 해커, 코드 위스퍼러 등 직함은 셀 수도 없다. 개발자를 가리키는 직함은 인상적이거나 겸손하거나 유행을 타거나 근엄하거나 전통적이거나 현대적인 느낌이 있다. 다양한 직함 속 개발자들은 매일은 아니더라도 적어도 일주일의 어느 정도는 컴퓨터 앞에서 소스 코드를 읽고 쓰는 데 시간을 보낸다는 공통점이 있다. 그런 이유로 ‘개발자’라는 용어로 대상 독자를 특정했다.
코딩은 상상력을 동원할 수 있는 가장 자유롭고 평등한 활동이다. 이론적으로, 신체적 기량에서 ‘두뇌’만 있다면 필요한 모든 것이 준비된 셈이다. 나이, 성별, 국적, 출신 중 어느 것도 장애물이 돼서는 안 된다. 특히 신체적 장애는 장애물이 될 수 없다.

우리는 말로 표현할 수 없을 만큼 운이 좋다. 우리는 수년간 테스트 주도 개발을 했다. 머큐리 우주 프로그램 코드를 작성한 개발자들이 펀치 카드로 테스트 주도 개발(Test-Driven Development, TDD)을 실천한 지도 수십 년이 지났다(https://oreil.ly/pKpSZ). 테스트 주도 개발적용을 수월하게 하는 XUnit 라이브러리는 세기를 거슬러 올라간다. 사실, 『테스트 주도 개발』(인사이트, 2014)을 저술하고 JUnit 프레임워크를 개발한 켄트 벡은 스스로 테스트 주도 개발의 실천(https://oreil.ly/zDyBr)을 발명이 아닌 ‘재발견’이라 말한다. 이 표현은 그의 겸손의 증거이면서도 사실이다. 테스트 주도 개발은 소프트웨어 개발만큼이나 오래됐다.
그렇다면 테스트 주도 개발이 표준 코드 작성 방식과 여전히 거리가 먼 이유는 무엇일까? 일정의 압박이 있을 때, 또는 IT 예산을 줄여야 할 때, 또는(개인적으로 가장 좋아하는) ‘소프트웨어 딜리버리 팀의 속도 향상’이 필요할 때 흔히 희생돼야 하는 첫 번째 대상이 테스트 주도 개발일까? 테스트 주도 개발은 결함 개수를 줄이고 설계를 더 간단하게 만들며 개발자 스스로가 갖는 코드에 대한 신뢰를 향상시키는 데 경험적이고 실험적인 증거가 있음에도 이런 모든 이유가 제시된다.
테스트 주도 개발이 마지못해 채택되거나 쉽게 버려지는 이유는 무엇일까? 테스트 주도 개발 실천을 꺼리는 이들이 주장은 크게 두 가지다.
첫째, 어디서부터 어떻게 시작해야 할지 모르겠다.
아마도 가장 흔한 이유는 인지도와 노출의 부족이다. 다른 기술과 같이, 테스트 주도 스타일의 코드 작성은 배워야 한다. 많은 개발자들은 이 기술을 배울 외적 동기(시간, 리소스, 지침, 격려)도 내적 동기(꺼리는 마음과 두려움 극복)도 없다.
둘째, 테스트 주도 개발은 토이 프로그램이나 인터뷰에서는 쓸 법하나 ‘실제 세계’ 코드 작성에는 제대로 작동하지 않는다.
사실이 아니지만 이해는 된다. 대부분의 테스트 주도 개발 튜토리얼과 이 책을 포함한 서적에서는 뻔한 도메인에서 비교적 간단한 예제를 선택하도록 강요한다. 상업적으로 배포된 애플리케이션(예: 금융 기관, 의료 관리 시스템, 자율주행자동차)에서 빼낸 소프트웨어 조각의 실제 코드를 바탕으로 테스트 주도 개발 기사나 책을 쓰기는 어렵다. 우선 한 가지 이유는, 실제 코드는 대부분 독점 소유권이 있으며 오픈 소스가 아니다. 다른 이유로는, 가장 많은 청중들에게 가장 폭넓은 관심을 가질 도메인의 코드를 보여주는 것은 저자의 역할이다. 고도로 전문적인 도메인의 문맥상에서 테스트 주도 개발을 보여주는 것은 애매함에 경계에 있어 비논리적이다. 그렇게 하려면 무엇보다 해당 도메인의 난해한 전문 용어와 은어들의 장황한 설명이 필요하다. 테스트 주도 개발을 이해하기 쉽고, 접근하기 쉬우며, 심지어 사랑스럽게 만들려는 저자의 의욕을 꺾게 될 것이다.
테스트 주도 개발 문헌에서 실제 세계 코드를 사용함에 있어 이런 장애물에도 불구하고, 개발자는 어김없이 테스트 주도 개발로 프로덕션 소프트웨어를 작성한다. 아마도 최고의 설득력 있는 예시는 JUnit 프레임워크(https://oreil.ly/UCPcg) 자체에 대한 단위 테스트 스위트일 것이다. 리눅스 커널(아마 세계에서 가장 활발히 사용되고 있는 소프트웨어 조각)은 단위 테스트를 바탕으로 개선되고 있다.
코드 작성부터 하고 테스트를 작성해도 충분하다. 테스트 주도 개발은 너무 제한적이고 현학적이다.
이 주장은 ‘단위 테스트는 지나치게 과대 평가됐다(https://oreil.ly/Y7S5M)’라고 가끔 큰소리치는 것을 듣는 것보다 더 신선하다! 프로덕션 코드를 작성한 후 작성하는 테스트는 아무런 테스트도 작성하지 않는 것보다는 낫다. 개발자가 자신의 코드에 신뢰를 높이고 우발적인 복잡성을 줄이며, 믿을 만한 문서를 제공하는 모든 일은 좋다. 다만, 단위 테스트를 프로덕션 코드를 작성하기 전에 작성하면, 임의의 복잡성의 발생을 예방하도록 강제하는 기능을 제공한다.
테스트 주도 개발은 다음 두 가지 실용적인 규칙을 방호책으로 제공해 더 간단한 설계를 할 수 있다.
1. 실패하는 테스트를 고치기 위해서만 프로덕션 코드를 작성하라.
2. 테스트가 그린일 때만 열성적으로 리팩터링하라.
우리가 작성하는 모든 코드를 자동으로 그리고 필연적으로 동작하는 가장 간단한 코드가 되도록 테스트 주도 개발이 보장하는가? 아니다. 그렇지 않다. 그렇게 할 수 있는 어떤 사례, 규칙, 책, 선언서는 없다. 단순성이 달성되고 유지되도록 이런 사례에 숨을 불어넣는 사람에게 달려 있다.
이 책은 테스트 주도 개발이 세 가지 다른 프로그래밍 언어에서 어떻게 작동하는지 설명하고 지도한다. 테스트 주도 개발을 꾸준히 연습하는 습관과 자신감을 심어주는 것이 목적이다. 야심에 찬 목적일 순 있지만 달성하기 힘들진 않기를 소망한다.

살림 시디퀴(Saleem Siddiqui)

소프트웨어 개발자, 교육자, 연사이자 저자다. 몇 번의 기술 호황과 불황이 반복되는 시기를 겪으며 의료, 유통, 관공서, 금융 및 제약 부문에서 크고 작은 팀의 일원으로 소프트웨어를 개발했다. 소프트웨어를 개발하는 동안 부끄러운지도 모른 채 저질렀던 실수에서 얻은 교훈을 다른 이들과 공유하고자 한다.
노력을 토대로 세계 무대로 나아가길 즐긴다. 경험을 글로 풀어 블로그(http://thesaleem.com/blog)에 게시하는데, 가끔은 제삼자의 관점에서 쓴 글도 볼 수 있다.

여러 프로그래밍 언어로 소프트웨어를 개발하는 접근 방식인 폴리글랏 프로그래밍은, 다양한 언어의 장점을 활용해 보다 유연하고 최적의 성능과 확장성을 제공하는 소프트웨어 개발을 가능케 한다. 한 언어만 고수하는 소프트웨어 개발자가 아닌 이상 자의 또는 타의에 의해 여러 프로그래밍 언어를 접하게 되며, 자연스레 폴리글랏 프로그래밍을 하는 상황에 놓인다.
단위 테스트 코드 작성을 기본으로 하는 테스트 주도 개발 방식은, 소프트웨어가 테스트 가능한(Testable) 구조를 갖도록 강제하며, 이로 인해 보다 간단하면서도 구조화된 설계로 이끌어줄 뿐만 아니라 코드의 신뢰도를 높일 수 있는 효과적인 방법이다.
이 책에서는 개발자에게 사랑받는 Go, 자바스크립트, 파이썬의 세 가지 프로그래밍 언어로 테스트 주도 개발을 실천하는 실용적 방법을 제공한다. 켄트 벡의 저서 『테스트 주도 개발』(인사이트, 2014)에서 다룬 ‘돈 문제’ 예제를 각 언어로 재해석해 쉽고 재밌게 테스트 주도 개발 방식에 익숙해질 수 있도록 설명했다.
테스트 주도 개발은 지속적 통합 및 회귀 테스트를 자동화해 빠르고 정확하게 결함을 발견할 수 있게 하며, 켄트 벡이 얘기했듯이 소프트웨어 개발자 자신이 작성한 코드에 대한 두려움을 관리하는 데 효과적이다. 윤오영 작가의 수필 「방망이 깎던 노인」에서 방망이 장인이 질 좋은 방망이 하나를 깎아내는 데 노련하게 무던히 애를 쓰듯이, 소프트웨어 개발자 또한 품질 좋은 소프트웨어를 개발하기 위해 많은 수고를 아끼지 않는다. 테스트 주도 개발은 질 좋은 방망이와 같은 소프트웨어를 깎아내게끔 하는 정교하고 견고한 도구이기에 소프트웨어 개발자라면 반드시 경험하고 체득해야 한다고 생각한다.
시간은 좀 흘렀으나 2015년에 구글, 넷플릭스, 어도비 본사에 직접 방문한 적이 있다. 현업 개발자들로부터 이야기를 들을 기회가 있었는데, 각 회사의 소프트웨어 테스팅에 대한 인식과 노력은 정말 인상적이었다. 이후 여러 프로젝트에서 다양한 프로그래밍 언어(C/C++, Go, 파이썬, 코틀린, 자바)로 개발하며 테스트 주도 개발 및 단위 테스트에 계속 관심을 두게 됐다. 이 책을 통해 테스트 주도 개발의 가치를 이해하고 그 과정을 즐길 수 있기를 희망한다.

김인태

컴퓨터공학을 전공했고, 모바일 단말, 자동차 전장, 미디어 스트리밍 분야에서 다수의 소프트웨어 개발 프로젝트에 참여했다. 그 과정을 통해 다양한 프로그래밍 언어와 시스템 환경에서 소프트웨어 개발 경험을 쌓았다. 14년차 소프트웨어 엔지니어로 일하고 있으며, 국내 소프트웨어 테스트 전문가 자격 시험인 TTA 주관 CSTS의 시험 위원으로도 활동하고 있다.