»
S
I
D
E
B
A
R
«
[역서] JUnit in Action: 단위 테스트의 모든 것
June 24th, 2011 by Wegra Lee

JUnit in Action : 단위 테스트의 모든 것

  • ISBN-13: 9788966260065
  • ISBN-10: 8966260063
  • 저자: 피터 타치브, 펠리페 레미, 빈센트 마솔, 게리 그레고리
  • 역자: 이복연 (Wegra Lee)
  • 출판사: 인사이트
  • 원서: JUnit in Action, Second Edition

목차

1부 JUnit 기본

1장 JUnit 첫걸음
1.1 동작 증명하기
1.2 밑그림부터 시작하기
1.3 단위 테스트 프레임워크 이해하기
1.4 JUnit의 설계 목표
1.5 JUnit 셋업하기
1.6. JUnit으로 테스트 실행하기

2장 JUnit 핵심 들여다보기
2.1. JUnit의 핵심
2.2 파라미터화 테스트 실행하기
2.3 JUnit 테스트 러너
2.4 스위트를 이용한 테스트 조직하기

3장 JUnit 마스터하기
3.1 컨트롤러 컴포넌트 소개
3.2 자! 이제 테스트다!
3.3 예외 처리 테스트하기
3.4 타임아웃 테스트하기
3.5 Hamcrest 매처 소개
3.6 테스트 프로젝트 셋업하기

4장 소프트웨어 테스트 원칙
4.1 단위 테스트가 필요한 이유
4.2. 테스트의 종류
4.3 블랙박스 테스트와 화이트박스 테스트

2부 다채로운 테스트 전략

5장 테스트 커버리지와 개발
5.1 테스트 커버리지 측정하기
5.2. 테스트 가능한 코드 작성하기
5.3. 테스트 주도 개발
5.4 개발 주기에서의 테스트

6장 스텁을 활용한 포괄적인 테스트
6.1. 스텁이란?
6.2 HTTP 커넥션을 스텁으로 대체하기
6.3 웹 서버의 리소스를 스텁으로 대체하기
6.4 커넥션 스텁 작성하기

7장 목 객체를 활용한 테스트
7.1 목 객체 소개하기
7.2 목 객체를 활용해 단위 테스트하기
7.3 목 객체와 함께 리팩터링하기
7.3.1 예제 리팩터링하기
7.4 HTTP 커넥션을 목으로 대체하기
7.5 목 객체를 트로이 목마로 사용하기
7.6 목 프레임워크 만나보기

8장 In-container 테스트
8.1 표준 단위 테스트의 한계
8.2 목 객체를 이용한 해법
8.3 In-container 테스트
8.4 스텁, 목 객체, In-container 테스트 비교하기

3부 JUnit과 빌드 프로세스

9장 Ant로 JUnit 테스트 실행하기
9.1 개발자의 하루
9.2 Ant로 테스트 실행하기
9.3 Ant 소개 및 설치하기
9.4 Ant의 타깃, 프로젝트, 속성, 태스크 알아보기
9.4.1 javac 태스크
9.4.2 junit 태스크
9.5 Ant 실행하기
9.6 Ivy를 이용한 종속성 관리
9.7 HTML 보고서 생성하기
9.8 테스트 일괄 수행하기

10장 Maven2로 JUnit 테스트 실행하기
10.1 Maven의 특성
10.2 Maven 프로젝트 구성하기
10.3 Maven 플러그인 소개하기
10.4 Maven의 부정적 측면

11장 지속적 통합 툴
11.1 지속적 통합의 맛
11.2 구원투수 CruiseControl
11.3 또 하나의 멋진 구원자 Hudson
11.4 지속적 통합으로 얻는 이점

4부 JUnit 확장

12장 표현 계층 테스트하기
12.1 테스트 프레임워크 선택하기
12.2 HtmlUnit 소개하기
12.3 HtmlUnit 테스트 작성하기
12.4 HtmlUnit과 Cactus 함께 사용하기
12.5 Selenium 소개
12.6 Selenium 테스트 생성하기
12.7 Selenium 테스트 실행하기
12.8 Selenium 테스트 작성하기
12.9 HtmlUnit vs. Selenium

13장 Ajax 테스트하기
13.1 Ajax 애플리케이션 테스트는 왜 어려운가?
13.2 Ajax 테스트 패턴
13.3 기능 테스트
13.4 자바스크립트 테스트하기
13.5 RhinoUnit vs. JsUnit
13.6 JSLint로 모범 사례 이행 여부 검사하기
13.7 HttpClient로 서비스 테스트하기
13.8 Google Web Toolkit 애플리케이션 테스트하기

14장 Cactus를 이용한 서버단 자바 테스트하기
14.1 Cactus란 무엇인가?
14.2 Cactus를 이용해 테스트하기
14.3 서블릿과 필터 테스트하기
14.4 JSP 테스트하기
14.5 EJB 테스트하기
14.6 Cargo란 무엇인가?
14.7 Ant로 Cactus 테스트 실행하기
14.8 Maven2x를 이용해 Cactus 테스트 실행하기
14.9 브라우저로부터 Cactus 테스트 실행하기

15장 JSP 애플리케이션 테스트하기
15.1 JSF 소개하기
15.2 애플리케이션 예제 소개하기
15.3 JSF 애플리케이션 테스트 시의 전형적인 난관들
15.4 JSF 애플리케이션 테스트 전략
15.5 JSFUnit으로 예제 애플리케이션 테스트하기
15.6 JSFUnit과 HtmlUnit 함께 사용하기
15.7 JSF 애플리케이션 성능 테스트하기

16장 OSGi 컴포넌트 테스트하기
16.1 OSGi 소개하기
16.2 첫 번째 OSGi 서비스
16.3 OSGi 서비스 테스트하기
16.4 JUnit4OSGi 소개하기

17장 데이터베이스 액세스 테스트하기
17.1 데이터베이스 단위 테스트 임피던스 미스매치
17.2 DbUnit 소개하기
17.3 데이터셋을 이용해 데이터베이스 채우기
17.4 데이터셋으로 데이터베이스 상태 확인하기
17.5 ReplacementDataSet를 이용해 데이터 변환하기
17.6 데이터베이스 안의 데이터로부터 데이터셋 생성하기
17.7 고급 기법
17.8 데이터베이스 액세스 테스트 모범 사례

18장 JPA 기반 애플리케이션 테스트하기
18.1 계층형 애플리케이션 테스트하기
18.2 JPA 테스트의 특징
18.3 인프라 갖추기
18.4 JPA 엔티티 매핑 테스트하기
18.5 JPA 기반 DAO 테스트하기
18.6 외래키 이름 테스트하기

19장 JUnit에 부스터를…
19.1 툴 소개
19.2 투명 목 활용
19.3 DbUnit 통합
19.4 assert는 일을 쉽게 만든다
19.5 리플렉션을 이용해 캡슐화 회피하기

부록A JUnit 3와 4의 차이점
A.1 전반적인 변화
A.2 API의 변화
A.3 애노테이션과 정적 임포트의 도입
A.4 추가된 JUnit 러너
A.5 새로운 assert 문과 가정

부록B 커스텀 러너와 매처로 JUnit API 확장하기
B.1 인터셉터 패턴 소개하기
B.2 커스텀 러너 제작하기
B.3 커스텀 매처 구현하기

역자 서문

개발자로써 10년 가까이 IT 분야에 종사하면서, 선후배 동료 개발자들에게 느낀 가장 큰 아쉬움 세 가지를 뽑자면, 개발 프로세스에 대한 관심 부족, 미흡한 툴 활용력, 마지막으로 단위 테스트의 중요성에 대한 인식 부족이다.

개발자 개개인의 잘못보다는 환경적인 요인이 크다. 예를 들어, 대학 교육을 마쳐도 소스 컨트롤, 지속적 통합, 리팩터링, 단위 테스트, 결함 관리 등과 같이 팀 개발 효율성과 제품 품질에 지대한 영향을 미치는 필수 개념들에 대해 제대도 들어보지도 못하고 사회의 문을 두드리는 경우가 허다하다.

이 책은 단위 테스트 프레임워크의 어머니라 할 수 있는 JUnit을 중심으로, 단위 테스트의 효과와 중요성, 성격이 다른 소프트웨어 각 영역별 지원 툴, 이들을 개발 프로세스에 녹이고 자동화시키는 방법까지, 내가 아쉬워했던 세 가지 영역을 골고루 아우른다. 더욱이 현업에 바로 적용할 수 있는 예제들을 중심으로 기본적인 이론과 다수의 모범 사례 등 알찬 내용들로 속이 꽉 채워져 있다.

물론 이것만으로 소프트웨어 개발을 논하기엔 부족함이 많지만, 프로페셔널 개발자로써 부끄럽지 않은 자신을 준비하는데는 후회 없는 선택이 될 것임을 확신한다.

나는 이 책에서 배운 것을 기반으로 독자들이 꼭 실천해보았으면 하는 것이 하나 있다. 바로 테스트 주도 개발(Test Driven Development)이다. 다름 아닌 독자들의 설계 역량 향상을 위해서이다. 테스트에서 설계역량을 논하는게 어색하다고 생각한다면 테스트를 절반밖에 이해하지 못한 것이다. 테스트와 설계는 맞닿아 있다.

설계와 구현을 먼저 하고 테스트가 뒤따르는 전통적 개발 프로세스에서의 테스트 케이스 제작은 “도메인(테스트 대상) 객체에 대한 분석력”만 있으면 가능하다. 쓰임새를 정확히 이해하고, 무엇을 검증해야 할 지와 개발자들이 주로 실수하는 부분이 어디인지를 잘 알고 있다면 좋은 테스트 케이스를 만들 수 있다.

반면 테스트 주도 개발에서의 테스트 케이스 제작이란 “구현 대상의 기능 요구사항을 (자연어가 아닌) 프로그래밍 언어로 기술하는 것”이다. 이는 개발자들을 자신이 만들 API의 사용자(고객) 입장에 서서 기능 제공 수준을 넘어, 사용성까지 고려한 설계를 하도록 이끈다. 결과로 우리가 얻는 것은 두 가지. 더 나은 설계의 제품과, 개발자의 설계 역량 향상이다. 당장의 제품 개발과 직접적으로 연관된다는 측면에서 관리자를 설득할 때는 전자가 더 효과적일 지 모르지만, 나는 후자의 값어치를 훨씬 높이 평가한다.

테스트 용이성과 좋은 설계의 상관관계가 잘 와 닿지 않는다면, 테스트하기 어려운 코드의 일반적인 특성을 살펴보면 도움이 된다. 대표적인 몇 가지를 나열해보았다.

- 인터페이스가 복잡하다: 사용법 자체를 이해하기 어렵거나 경우의 수가 너무 많아 충분히 테스트할 수 없다.
- 인터페이스가 직관적이지 않다 (혹은 모호하다): 사용법을 오해하기 쉽다.
- 인터페이스가 부족하다: 원하는 조건으로 설정하거나, 수행 결과를 확인할 길이 없다.
- 종속된 다른 모듈(혹은 환경)이 많거나, 숨은 종속성을 갖는다: 테스트 환경을 갖추기 어렵고, 문제의 원인을 찾기 어렵다.
- 모듈간 일관성이 부족하다: 다른 모듈과 똑같은 방식으로 사용했으나 문제가 발생한다.

어떠한가? 이를 반대로 하면 좋은 설계의 요건들과 너무도 흡사하지 않은가? 때문에 테스트할 수 있도록, 나아가 테스트하기 쉽도록 만들려는 고민은 자연스럽게 더 좋은 설계를 찾는 과정으로 이어지고, 그 경험과 깨달음과 개발자의 머릿속에 축적된다. 실제로 제어 역전과 같은 설계 패턴이 잘 적용된 설계와 그렇지 않은 설계의 테스트 용이성은 극명한 차이가 난다.

뿐만 아니라 설계의 좋고 나쁨을 판단함에 있어 ‘나는 왠지 이 디자인이 더 마음에 든다’나 ‘다른 제품을 보니 이렇게 했더라’ 보다 ‘테스트를 할 수 있다/없다’는 훨씬 명확하고 신뢰할만한 기준이 되어준다.

이런 이유들로 나는 “테스트 주도 개발보다 더 효과적인 설계 훈련법은 없다”고 생각하며, “단위 테스트 잘하는 개발자 치고 실력 없는 사람이 없다”는 믿음에 배신 당한 적이 없다.

그렇다면 이 책을 건너뛰고 테스트 주도 개발로 바로 넘어가 보는 것은 어떨까? 한마디로 굉장히 위험한 발상이며, 아마도 실패를 맛볼 것이다. 좋은 단위 테스트를 만들기란, 좋은 설계를 하는 것만큼이나 쉽지 않기 때문이다. 더욱이 나쁜 설계라도 대부분은 구현해낼 수는 있지만, 이를 단위 테스트한다는 것은 현실적으로 불가능하거나 투자한 노력 대비 소득이 너무 적을 가능성이 높다. 수많은 테스트 프레임워크들과 지원 툴들이 시장에 괜히 나와 있는 것이 아니다.

이 책을 통해 테스트 프레임워크가 제공해주는 다양한 기능과 시의 적절하게 사용할 수 있는 각종 지원 툴들, 그리고 모범 사례들을 익히며 공력을 쌓다보면, 향후 테스트 주도 개발로의 성공적인 이행에 큰 보탬이 되리라 확신한다.

자~ 그럼! 저자들과 역자의 노력, 그리고 인사이트 출판사의 선택이 부디 많은 한국 개발자들의 실력 향상에 비옥한 밑거름이 되어주길 바라며, 이만……


»  Substance: WordPress   »  Style: Ahren Ahimsa