|
|
|
 |
판매가 |
48,000원 → 43,200원  10% |
|
|
마일리지 |
 10% 4,320원 |
|
|
발행일 |
2010-03-12
|
|
ISBN |
8960771252 | 9788960771253
|
|
기타정보 |
번역서 | 1056쪽
|
|
|
예상출고일
|
1일 (근무일기준) |
|
배송비 |
무료배송
|
| |
|
|
|
|
|
 |
| 소프트웨어
|
|
|
| 종합지수 15p 40 위 |
|
| 월간지수 21p 2 위 |
|
|
| |
|
※ 네이버 체크아웃으로 구매시 비회원으로 구매가
됨으로 강컴 마일리지는 적립 되지 않습니다. |
|
|
|
 |
|
[출판사서평]
< 요약 >
『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년만 더 빨리 읽었더라면 삽질을 덜 했을 텐데’ 하는 생각에 아쉬움도 들더군요. ‘우리 프로젝트에서는 어떻게 적용해볼 수 있을까’를 생각하면서 읽으면 더 재미있게 보실 수 있습니다. 이해가 잘 안 될 때는 예제 코드를 먼저 보세요. 때로는 천마디 글보다 한 줄의 코드가 더 이해하기 쉬울 때가 있으니까요.
|
 |
|
 |
1부 설명
1장 간단하게 둘러보기
개요
가장 확실하면서도 간단한 테스트 자동화 전략
개발 프로세스
고객 테스트
단위 테스트
테스트하기 쉬운 설계
테스트 조직
정리
2장 테스트 냄새 85
개요
테스트 냄새 소개
테스트 냄새란?
테스트 냄새의 종류
냄새가 날 때 대처 방안
냄새 분류
프로젝트 냄새
동작 냄새
코드 냄새
정리
3장 테스트 자동화의 목표
개요
테스트를 하는 이유
테스트 자동화 경제학
테스트 자동화의 목표
테스트는 품질 향상에 도움이 돼야 한다
테스트는 SUT를 이해하는 데 도움이 돼야 한다
테스트는 위험을 줄여야(추가하지도 않아야) 한다
테스트는 실행하기 쉬워야 한다
테스트는 만들고 유지하기 쉬워야 한다
테스트는 두 가지 이유로 복잡해진다
시스템이 발전하는 동안 테스트에 필요한 유지 보수 비용이 최소화돼야 한다
정리 108
4장 테스트 자동화의 철학
개요
철학이 중요한 이유
철학적 차이점
테스트 먼저냐 테스트 나중이냐?
테스트냐 예제냐?
단계별 테스트냐 한꺼번에 테스트냐?
밖에서 안으로냐 안에서 밖으로냐?
동작 검증이냐 상태 검증이냐?
픽스처를 미리 설계하기냐 픽스처를 단계별 테스트에 따라 설계하기냐?
철학이 다를 때
나의 철학
정리
5장 테스트 자동화의 원칙
개요
원칙
정리
6장 테스트 자동화 전략
개요
무엇이 전략적인가?
어떤 종류의 테스트를 자동화해야 하는가?
기능별 테스트
교차 기능 테스트
어떤 테스트 자동화에는 어떤 도구를 사용하는가?
테스트 자동화 방식과 방법
xUnit 소개
xUnit의 스윗 스팟
어떤 테스트 픽스처 전략을 사용하는가?
무엇이 픽스처인가?
주요 픽스처 전략
1회용 신선한 픽스처
지속되는 신선한 픽스처
공유 픽스처 전략
테스트 용이성을 보장하는 방법
테스트 나중 - 각오가 돼 있는가?
테스트하기 쉬운 설계 - 미리 하기
테스트 주도 테스트 용이성
제어 위치와 관찰 위치
상호작용 방식과 테스트 용이성 패턴
나눈 후 테스트
정리
7장 xUnit 기초
개요
xUnit 소개
공통 특징
최소한 알아야 할 것
테스트 정의하기
픽스처란?
테스트들의 스위트 정의
테스트 실행
테스트 결과
xUnit의 내부
테스트 명령
테스트 스위트 객체
절차적 세상에서의 xUnt
정리
8장 1회용 픽스처 관리
개요
테스트 픽스처 용어
픽스처란?
신선한 픽스처란?
무엇이 1회용 신선한 픽스처인가?
신선한 픽스처 생성
인라인 픽스처 설치
위임 픽스처 설치
암묵적 픽스처 설치
혼합형 픽스처 설치
1회용 신선한 픽스처 해체하기
정리
9장 지속되는 픽스처 관리
개요
지속되는 신선한 픽스처 관리
무엇이 픽스처를 지속하게 만드는가?
지속되는 신선한 픽스처로 인해 생기는 문제
지속되는 신선한 픽스처 해체하기
해체 코드를 아예 필요 없게 만들기
느린 테스트에 대처하기
공유 픽스처 관리
공유 픽스처 접근하기
공유 픽스처 생성자 호출하기
정리
10장 결과 검증
개요
자체 검사 테스트 만들기
상태 검증이냐 동작 검증이냐?
상태 검증
내장 단언문 사용하기
델타 단언문
외부 결과 검증
동작 검증
절차형 동작 검증
기대 동작 명세
테스트 코드 중복 줄이기
기대 객체
맞춤 단언문
결과를 설명하는 검증 메소드
인자를 받는 테스트와 데이터 주도 테스트
테스트 내 조건문 로직 피하기
if문 제거하기
반복문 제거하기
기타 기법
거꾸로, 밖에서 안으로 작업하기
테스트 주도 개발로 테스트 유틸리티 메소드 작성하기
재사용 가능한 검증 로직을 둘 위치
정리
11장 테스트 대역 사용
개요
간접 입력과 간접 출력
간접 입력을 신경 써야 하는 이유
간접 출력을 신경 써야 하는 이유
간접 입력은 어떻게 제어할 수 있을까?
간접 출력은 어떻게 검증할 것인가?
대역으로 테스트하기
테스트 대역의 종류
테스트 대역 제공하기
테스트 대역 설정하기
테스트 대역 설치하기
테스트 대역의 다른 용도
내시경 테스팅
필요 주도 개발
픽스처 설치 빠르게 하기
테스트 실행 빠르게 하기
기타 고려 사항
정리
12장 테스트 조직하기
개요
기본 xUnit 메커니즘
적당한 크기의 테스트 메소드
테스트 메소드와 테스트케이스 클래스
클래스별 테스트케이스 클래스
기능별 테스트케이스 클래스
픽스처별 테스트케이스 클래스
테스트 메소드 조직 전략 선택하기
테스트 이름 규약
테스트 스위트 조직하기
테스트 집단 실행하기
하나의 테스트 실행하기
테스트 코드 재사용
테스트 유틸리티 메소드 위치
테스트케이스 상속과 재사용
테스트 파일 구성
내장 자체 테스트
테스트 패키지
테스트 의존
정리
13장 데이터베이스와 테스트
개요
데이터베이스 테스트하기
데이터베이스를 이용한 테스트가 필요한 이유
데이터베이스와 관련된 문제
데이터베이스 없이 테스트하기
데이터베이스 테스트하기
저장 프로시저 테스트하기
데이터 접근 레이어 테스트하기
개발자의 독립성 보장하기
데이터베이스로 테스트하기(한 번 더!)
정리
14장 효과적인 테스트 자동화를 위한 길잡이
개요
테스트 자동화의 어려움
자동 테스트를 유지 보수하기 좋게 만드는 길잡이
주요 경로 코드 실행
주요 경로의 직접 출력 값 검증
대안 경로 검증
간접 출력 동작 검증
테스트 실행과 유지 보수 최적화
정리
2부 테스트 냄새
15장 코드 냄새
애매한 테스트(Obscure Test)
테스트 내 조건문 로직(Conditional Test Logic)
테스트하기 힘든 코드(Hard-to-Test Code)
테스트 코드 중복(Test Code Duplication)
제품 코드 내 테스트 로직(Test Logic in Production)
16장 동작 냄새
단언 룰렛(Assertion Roulette)
변덕스러운 테스트(Erratic Test)
깨지기 쉬운 테스트(Fragile Test)
잦은 디버깅(Frequent Debugging)
수동 조정(Manual Intervention)
느린 테스트(Slow Test)
17장 프로젝트 냄새
버그투성이 테스트(Buggy Test)
테스트를 작성하지 않는 개발자(Developers Not Writing Test)
높은 테스트 유지 비용(High Test Maintenance Cost)
제품 버그(Production Bug)
3부 패턴
18장 테스트 전략 패턴
기록 테스트(Recorded Test)
스크립트 기반 테스트(Scripted Test)
데이터 주도 테스트(Data-Driven Test)
테스트 자동 프레임워크(Test Automation Framework)
최소 픽스처(Minimal Fixture)
표준 픽스처(Standard Fixture)
신선한 픽스처(Fresh Fixture)
공유 픽스처(Shared Fixture)
뒷문 조작(Back Door Manipulation)
레이어 테스트(Layer Test)
19장 xUnit 기본 패턴
테스트 메소드(Test Method)
4단계 테스트(Four-Phase Test)
단언 메소드(Assertion Method)
단언 메시지(Assertion Message)
테스트케이스 클래스(Testcase Class)
테스트 실행기(Test Runner)
테스트케이스 객체(Testcase Object)
테스트 스위트 객체(Test Suite Object)
테스트 찾기(Test Discovery)
테스트 나열(Test Enumeration)
테스트 선택(Test Selection)
20장 픽스처 설치 패턴
인라인 설치(In-line Setup)
위임 설치(Delegated Setup)
생성 메소드(Creation Method)
암묵적 설치(Implicit Setup)
미리 만든 픽스처(Prebuilt Fixture)
지연 설치(Lazy Setup)
스위트 픽스처 설치(Suite Fixture Setup)
설치 데코레이터(Setup Decorator)
엮인 테스트(Chained Test)
21장 결과 검증 패턴
상태 검증(State Verification)
동작 검증(Behavior Verification)
맞춤 단언문(Custom Assertion)
델타 단언문vDelta Assertion)
보호 단언문(Guard Assertion)
작업 중인 테스트 단언문(Unfinished Test Assertion)
22장 픽스처 해체 패턴
가비지 컬렉션 해체(Garbage-Collected Teardown)
자동 해체(Automated Teardown)
인라인 해체(In-line Teardown)
암묵적 해체(Implicit Teardown)
23장 테스트 대역 패턴
테스트 대역(Test Double)
테스트 스텁(Test Stub)
테스트 스파이(Test Spy)
모의 객체(Mock Object)
가짜 객체(Fake Object)
설정되는 테스트 대역(Configurable Test Double)
하드 코딩된 테스트 대역(Hard-Coded Test Double)
테스트용 하위클래스(Test-Specific Subclass)
24장 테스트 조직 패턴
이름 있는 테스트 스위트(Named Test Suite)
테스트 유틸리티 메소드(Test Utility Method)
인자를 받는 테스트(Parameterized Test)
클래스별 테스트케이스 클래스(Testcase Class per Class)
기능별 테스트케이스 클래스(Testcase Class per Feature)
픽스처별 테스트케이스 클래스(Testcase Class per Fixture)
테스트케이스 상위클래스(Testcase Superclass)
테스트 도우미(Test Helper)
25장 데이터베이스 패턴
데이터베이스 샌드박스(Database Sandbox)
저장 프로시저 테스트(Stored Procedure Test)
테이블 삭제 해체(Table Truncation Teardown)
트랜잭션 롤백 해체(Transaction Rollback Teardown)
26장 테스트하기 쉬운 패턴
의존 주입(Dependency Injection)
의존 찾기(Dependency Lookup)
대강 만든 객체(Humble Object)
테스트 훅(Test Hook)
27장 갑 패턴
리터럴 값(Literal Value)
파생 값(Derived Value)
생성 값(Generated Value)
더미 객체(Dummy Object)
4부 부록
부록 A 테스트 리팩토링
부록 B xUnit 용어 정리
부록 C xUnit 계열
부록 D 도구
부록 E 목표와 원칙
부록 F 냄새, 별명, 원인
부록 G 패턴, 별명, 변형
|
|
|
 |
[저자소개]
제라드 메스자로스(Gerard Meszaros)
캘거리(Calgary)에 있는 애자일 개발 전문 컨설팅 회사 클리어스트림 컨설팅(ClearStream Consulting)의 수석 과학자(Chief Scientist)이자 선임 컨설턴트다. 제라드는 십 년 이상 자동 단위 테스트 프레임워크 분야에서 경험을 쌓았고 테스트 자동 패턴, 소프트웨어와 테스트 리팩토링, 테스트 용이성을 위한 설계 분야를 선도하는 전문가다.
[역자소개]
박일
연세대 컴퓨터과학과를 졸업했다. 2000년 초에 개발을 시작해 지금은 리니지2 서버 팀에서 근무 중이다. 옮긴 책으로는 『스크럼』(2008년)이 있다.
|
|
|
|
|
|
|
|
|
|
|
|
|
Home > 
POD(Printed On Demand)
