상세정보
자바와 JUnit을 활용한 실용주의 단위 테스트
- 저자
- 제프 랭어
- 출판사
- 길벗
- 출판일
- 2019-06-30
- 등록일
- 2021-01-28
- 파일포맷
- EPUB
- 파일크기
- 0
- 공급사
- 교보문고
- 지원기기
-
PC
PHONE
TABLET
프로그램 수동설치
뷰어프로그램 설치 안내
책소개
『실용주의 프로그래머』의 앤디 헌트와 데이브 토마스가 알려주는
실용주의 단위 테스트!
클린 코드의 핵심인 단위 테스트, 어디서 어떻게 시작해야 할까? 책에서는 단위 테스트의 개념과 작성 이유부터 테스트 가이드라인, 목 객체 사용법, 자동화된 단위 테스트, 리팩토링까지 단위 테스트의 핵심 내용을 설명한다. 또한, 자바와 JUnit으로 단위 테스트를 단계별로 실습할 수 있게 구성했다. 단위 테스트가 처음이거나, 단위 테스트를 좀 더 깊게 이해하고 싶은 분들에게 추천한다.
저자소개
저자 : 제프 랭어
경력 30년 이상의 베테랑 소프트웨어 개발자로 소프트웨어 개발뿐만 아니라 개발 관련 코치를 겸하고 있다. Outpace Systems, Inc.에서 일했고 지금도 Langr Software Solutions, Inc.에서 고객을 돕고 있다. 『Agile in a Flash』(팀 오팅거 공저) 등을 집필했다.
저자 : 앤디 헌트
『실용주의 프로그래머』(인사이트, 2014)와 『애자일 프랙티스』(인사이트, 2007), 『실용주의 사고와 학습』(위키북스, 2010) 등 6권의 책을 집필 혹은 공저했으며, 전 세계 소프트웨어 개발 콘퍼런스에서 정기적으로 강연한다.
저자 : 데이브 토마스
멋진 기술을 전파하는 것을 좋아하는 프로그래머다. 『실용주의 프로그래머』의 공저자이며 애자일 선언문의 창시자 중 한 명이다. 집필서인 『프로그래밍 루비』(인사이트, 2015)는 루비 언어를 세상에 처음 소개했고 『레일스와 함께하는 애자일 웹 개발』(인사이트, 2007)은 레일즈 혁명을 촉발하는 데 기여했다.
역자 : 유동환
책 쓰는 프로그래머다. 연세대학교 정보대학원에서 경영정보학을 전공한 후 LG전자에서 안드로이드 앱을 개발했다. 최근에는 선행플랫폼개발팀으로 자리를 옮겨 차세대 모바일 기술 프로젝트를 진행 중이다. 『안드로이드를 위한 Gradle』과 『RxJava 프로그래밍』(공저)을 집필했고, 『Java 9 모듈 프로그래밍』, 『그레이들 레시피』 등을 번역했다.
목차
1부 단위 테스트의 기초
1장 첫 번째 JUnit 테스트 만들기
1.1 단위 테스트를 작성하는 이유
1.2 JUnit의 기본: 첫 번째 테스트 통과
__1.2.1 프로젝트 설정
__1.2.2 JUnit 테스트 좀 더 이해
__1.2.3 JUnit 실행
1.3 테스트 준비, 실행, 단언
1.4 테스트가 정말로 뭔가를 테스트하는가?
1.5 마치며
2장 JUnit 진짜로 써 보기
2.1 테스트 대상 이해: Profile 클래스
2.2 어떤 테스트를 작성할 수 있는지 결정
2.3 단일 경로 커버
2.4 두 번째 테스트 만들기
2.5 @Before 메서드로 테스트 초기화
2.6 이제 어떤가?
2.7 마치며
3장 JUnit 단언 깊게 파기
3.1 JUnit 단언
__3.1.1 assertTrue
__3.1.2 assertThat은 명확한 값을 비교
__3.1.3 중요한 햄크레스트 매처 살펴보기
__3.1.4 부동소수점 수를 두 개 비교
__3.1.5 단언 설명
3.2 예외를 기대하는 세 가지 방법
__3.2.1 단순한 방식: 애너테이션 사용
__3.2.2 옛 방식: try/catch와 fail
__3.2.3 새로운 방식: ExpectedException 규칙
__3.2.4 예외 무시
3.3 마치며
4장 테스트 조직
4.1 AAA로 테스트 일관성 유지
4.2 동작 테스트 vs 메서드 테스트
4.3 테스트와 프로덕션 코드의 관계
__4.3.1 테스트와 프로덕션 코드 분리
__4.3.2 내부 데이터 노출 vs 내부 동작 노출
4.4 집중적인 단일 목적 테스트의 가치
4.5 문서로서의 테스트
__4.5.1 일관성 있는 이름으로 테스트 문서화
__4.5.2 테스트를 의미 있게 만들기
4.6 @Before와 @After (공통 초기화와 정리) 더 알기
__4.6.1 BeforeClass와 AfterClass 애너테이션
4.7 녹색이 좋다: 테스트를 의미 있게 유지
__4.7.1 테스트를 빠르게
__4.7.2 테스트 제외
4.8 마치며
2부 빠른 암기법 습득
5장 좋은 테스트의 FIRST 속성
5.1 FIRST: 좋은 테스트 조건
5.2 [F]IRST: 빠르다
5.3 F[I]RST: 고립시킨다
5.4 FI[R]ST: 좋은 테스트는 반복 가능해야 한다
5.5 FIR[S]T: 스스로 검증 가능하다
5.6 FIRS[T]: 적시에 사용한다
5.7 마치며
6장 Right-BICEP: 무엇을 테스트할 것인가?
6.1 [Right]-BICEP: 결과가 올바른가?
6.2 Right-[B]ICEP: 경계 조건은 맞는가?
6.3 경계 조건에서는 CORRECT를 기억하라
6.4 Right-B[I]CEP: 역 관계를 검사할 수 있는가?
6.5 Right-BI[C]EP: 다른 수단을 활용하여 교차 검사할 수 있는가?
6.6 Right-BIC[E]P: 오류 조건을 강제로 일어나게 할 수 있는가?
6.7 Right-BICE[P]: 성능 조건은 기준에 부합하는가?
6.8 마치며
7장 경계 조건: CORRECT 기억법
7.1 [C]ORRECT: [C]onformance(준수)
7.2 C[O]RRECT: [O]rdering(순서)
7.3 CO[R]RECT: [R]ange(범위)
__7.3.1 불변성을 검사하는 사용자 정의 매처 생성
__7.3.2 불변 메서드를 내장하여 범위 테스트
7.4 COR[R]ECT: [R]eference(참조)
7.5 CORR[E]CT: [E]xistence(존재)
7.6 CORRE[C]T: [C]ardinality(기수)
7.7 CORREC[T]: [T]ime(시간)
7.8 마치며
3부 더 큰 설계 그림
8장 깔끔한 코드로 리팩토링하기
8.1 작은 리팩토링
__8.1.1 리팩토링의 기회
__8.1.2 메서드 추출: 두 번째로 중요한 리팩토링 친구
8.2 메서드를 위한 더 좋은 집 찾기
8.3 자동 및 수동 리팩토링
8.4 과한 리팩토링?
__8.4.1 보상: 명확하고 테스트 가능한 단위들
__8.4.2 성능 염려: 그러지 않아도 된다
8.5 마치며
9장 더 큰 설계 문제
9.1 Profile 클래스와 SRP
9.2 새로운 클래스 추출
9.3 명령-질의 분리
9.4 단위 테스트의 유지 보수 비용
__9.4.1 자신을 보호하는 방법
__9.4.2 깨진 테스트 고치기
9.5 다른 설계에 관한 생각들
9.6 마치며
10장 목 객체 사용
10.1 테스트 도전 과제
10.2 번거로운 동작을 스텁으로 대체
10.3 테스트를 지원하기 위한 설계 변경
10.4 스텁에 지능 더하기: 인자 검증
10.5 목 도구를 사용하여 테스트 단순화
10.6 마지막 하나의 단순화: 주입 도구 소개
10.7 목을 올바르게 사용할 때 중요한 것
10.8 마치며
11장 테스트 리팩토링
11.1 이해 검색
11.2 테스트 냄새: 불필요한 테스트 코드
11.3 테스트 냄새: 추상화 누락
11.4 테스트 냄새: 부적절한 정보
11.5 테스트 냄새: 부푼 생성
11.6 테스트 냄새: 다수의 단언
11.7 테스트 냄새: 테스트와 무관한 세부 사항들
11.8 테스트 냄새: 잘못된 조직
11.9 테스트 냄새: 암시적 의미
11.10 새로운 테스트 추가
11.11 마치며
4부 더 큰 단위 테스트 그림
12장 테스트 주도 개발
12.1 TDD의 주된 이익
12.2 단순하게 시작
12.3 또 다른 증분 추가
12.4 테스트 정리
12.5 또 다른 작은 증분
12.6 다수의 응답 지원: 작은 설계 우회로
12.7 인터페이스 확장
12.8 마지막 테스트들
12.9 문서로서의 테스트
12.10 TDD의 리듬
12.11 마치며
13장 까다로운