![[고정]메타북스](https://simage.kyobobook.co.kr/ink/images/prom/2021/banner/211123/bnK_10.jpg)
이 책의 이벤트
해외주문/바로드림/제휴사주문/업체배송건의 경우 1+1 증정상품이 발송되지 않습니다.-
인프콘 2022 교보문고도 함께 합니다! 발표 세션 주제별 추천..2022.08.08 ~ 2022.08.31 -
『클린코드』박재호 역자와 함께하는 개발자 북콘서트 사전신청!2022.07.22 ~ 2022.08.16 -
![개발자 매거진 <리드잇zine> 4호([교보단독 사은품] 개발자 매거진 <리드잇zine> 4호 )](http://image.kyobobook.co.kr//ink/images/prom/2022/book/220421_readit/bnJ_03.jpg)
[교보단독 사은품] 개발자 매거진 <리드잇zine> ..2022.05.10 ~ 2022.08.12 -
에이콘 도서 구매 시 메모리게임 카드pack 선택가능2022.01.10 ~ 2022.08.31 -
MANNING, O'REILLY, PACKT, WILE..2016.03.07 ~ 2022.12.31
| ISBN | 9791161755748(1161755748) |
|---|---|
| 쪽수 | 400쪽 |
| 크기 | 189 * 236 * 19 mm /755g 판형알림 |
| 이 책의 원서/번역서 | Unit Testing Principles, Practices, and Patterns / Khorikov, Vladimir |
책소개
이 책이 속한 분야
소프트웨어 개발에 있어 단위 테스트는 이제 선택이 아니라 필수가 됐다. 단위 테스트에 대한 오해를 바로잡고, 올바른 단위 테스트에 대한 원칙, 테스트를 작성하는 스타일과 효과적인 테스트를 위한 소프트웨어 아키텍처를 이해할 수 있다. 또한 단위 테스트를 통합 테스트와 구분하고, 둘의 차이와 각각 활용법과 적절한 작성법, 안티 패턴 등을 알 수 있다.
작가의 말
단위 테스트를 시도했던 첫 번째 프로젝트가 생각난다. 비교적 잘 진행된 프로젝트였지만, 종료된 후 테스트들을 살펴보고 나서 많은 시간 낭비를 했다고 생각했다. 대부분의 단위 테스트는 기대치를 설정하고 거미줄처럼 복잡한 의존성을 연결하는 데 많은 시간이 든다. 단지 컨트롤러에 있는 코드 세 줄이 올바른지 확인하는 것이었다. 테스트에서 정확히 무엇이 잘못됐는지는 바로 알 수는 없었지만, 내 균형 감각이 무언가 잘못됐다는 신호를 보냈다.
다행히도 단위 테스트를 포기하지 않고 이후 프로젝트에 계속 적용했다. 그러나 그 이후로 일반적인 (그 당시) 단위 테스트 관행을 둘러싼 의견 차이가 점점 커지고 있었다. 나는 몇 년 동안 단위 테스트에 관해 많은 글을 썼다. 그 글을 쓰면서 용케 첫 번째 테스트에서 정확히 무엇이 잘못됐는지를 결정할 수 있었고, 이 지식을 단위 테스트의 더 넓은 영역으로 일반화했다. 마침내 이 책으로 그 기간 동안의 모든 연구와 시행착오, 그리고 오류에 대해 (컴파일하고 정제하고 요약해서) 정점에 다다를 수 있었다.
프로그래밍 지침은 수학 이론과 같이 기본 원칙에서 파생돼야 한다고 생각해, 이 책을 그와 비슷한 방식으로 구성하려고 노력했다. 결론으로 바로 도달하거나 근거 없는 주장을 던지지 않고 백지상태로 시작해서, 바닥부터 점진적으로 주장을 세워나간다. 흥미롭게도, 이러한 기본 원칙을 세우면 가이드라인과 모범 사례는 종종 자연스럽게 별 영향이 없어진다.
단위 테스트는 사실상 소프트웨어 프로젝트의 필수 요소이다. 이 책은 단위 테스트의 모범 사례와 일반적인 안티 패턴에 대한 인사이트를 제공한다. 모두 읽고 나면 새로운 기술로 무장해서 유지 보수와 확장이 쉽게 프로젝트를 성공시키는 전문가가 되는 데 필요한 지식을 얻게 될 것이다.
다행히도 단위 테스트를 포기하지 않고 이후 프로젝트에 계속 적용했다. 그러나 그 이후로 일반적인 (그 당시) 단위 테스트 관행을 둘러싼 의견 차이가 점점 커지고 있었다. 나는 몇 년 동안 단위 테스트에 관해 많은 글을 썼다. 그 글을 쓰면서 용케 첫 번째 테스트에서 정확히 무엇이 잘못됐는지를 결정할 수 있었고, 이 지식을 단위 테스트의 더 넓은 영역으로 일반화했다. 마침내 이 책으로 그 기간 동안의 모든 연구와 시행착오, 그리고 오류에 대해 (컴파일하고 정제하고 요약해서) 정점에 다다를 수 있었다.
프로그래밍 지침은 수학 이론과 같이 기본 원칙에서 파생돼야 한다고 생각해, 이 책을 그와 비슷한 방식으로 구성하려고 노력했다. 결론으로 바로 도달하거나 근거 없는 주장을 던지지 않고 백지상태로 시작해서, 바닥부터 점진적으로 주장을 세워나간다. 흥미롭게도, 이러한 기본 원칙을 세우면 가이드라인과 모범 사례는 종종 자연스럽게 별 영향이 없어진다.
단위 테스트는 사실상 소프트웨어 프로젝트의 필수 요소이다. 이 책은 단위 테스트의 모범 사례와 일반적인 안티 패턴에 대한 인사이트를 제공한다. 모두 읽고 나면 새로운 기술로 무장해서 유지 보수와 확장이 쉽게 프로젝트를 성공시키는 전문가가 되는 데 필요한 지식을 얻게 될 것이다.
목차
1부. 더 큰 그림
1장. 단위 테스트 목표
1.1 단위 테스트 현황
1.2 단위 테스트 목표
1.2.1 좋은 테스트와 좋지 않은 테스트를 가르는 요인
1.3 테스트 스위트 품질 측정을 위한 커버리지 지표
1.3.1 코드 커버리지 지표에 대한 이해
1.3.2 분기 커버리지 지표에 대한 이해
1.3.3 커버리지 지표에 관한 문제점
1.3.4 특정 커버리지 숫자를 목표로 하기
1.4 무엇이 성공적인 테스트 스위트를 만드는가?
1.4.1 개발 주기에 통합돼 있음
1.4.2 코드베이스에서 가장 중요한 부분만을 대상으로 함
1.4.3 최소 유지비로 최대 가치를 끌어냄
1.5 이 책을 통해 배우는 것
요약
2장. 단위 테스트란 무엇인가
2.1 ‘단위 테스트’의 정의
2.1.1 격리 문제에 대한 런던파의 접근
2.1.2 격리 문제에 대한 고전파의 접근
2.2 단위 테스트의 런던파와 고전파
2.2.1 고전파와 런던파가 의존성을 다루는 방법
2.3 고전파와 런던파 비교
2.3.1 한 번에 한 클래스만 테스트하기
2.3.2 상호 연결된 클래스의 큰 그래프를 단위 테스트하기
2.3.3 버그 위치 정확히 찾아내기
2.3.4 고전파와 런던파 사이의 다른 차이점
2.4 두 분파의 통합 테스트
2.4.1 통합 테스트의 일부인 엔드 투 엔드 테스트
요약
3장. 단위 테스트 구조
3.1 단위 테스트를 구성하는 방법
3.1.1 AAA 패턴 사용
3.1.2 여러 개의 준비, 실행, 검증 구절 피하기
3.1.3 테스트 내 if 문 피하기
3.1.4 각 구절은 얼마나 커야 하는가?
3.1.5 검증 구절에는 검증문이 얼마나 있어야 하는가
3.1.6 종료 단계는 어떤가
3.1.7 테스트 대상 시스템 구별하기
3.1.8 준비, 실행, 검증 주석 제거하기
3.2 xUnit 테스트 프레임워크 살펴보기
3.3 테스트 간 테스트 픽스처 재사용
3.3.1 테스트 간의 높은 결합도는 안티 패턴이다
3.3.2 테스트 가독성을 떨어뜨리는 생성자 사용
3.3.3 더 나은 테스트 픽스처 재사용법
3.4 단위 테스트 명명법
3.4.1 단위 테스트 명명 지침
3.4.2 예제: 지침에 따른 테스트 이름 변경
3.5 매개변수화된 테스트 리팩터링하기
3.5.1 매개변수화된 테스트를 위한 데이터 생성
3.6 검증문 라이브러리를 사용한 테스트 가독성 향상
요약
2부. 개발자에게 도움이 되는 테스트 만들기
4장. 좋은 단위 테스트의 4대 요소
4.1 좋은 단위 테스트의 4대 요소 자세히 살펴보기
4.1.1 첫 번째 요소: 회귀 방지
4.1.2 두 번째 요소: 리팩터링 내성
4.1.3 무엇이 거짓 양성의 원인인가?
4.1.4 구현 세부 사항 대신 최종 결과를 목표로 하기
4.2 첫 번째 특성과 두 번째 특성 간의 본질적인 관계
4.2.1 테스트 정확도 극대화
4.2.2 거짓 양성과 거짓 음성의 중요성: 역학 관계
4.3 세 번째 요소와 네 번째 요소: 빠른 피드백과 유지 보수성
4.4 이상적인 테스트를 찾아서
4.4.1 이상적인 테스트를 만들 수 있는가?
4.4.2 극단적인 사례 1: 엔드 투 엔드 테스트
4.4.3 극단적인 사례 2: 간단한 테스트
4.4.4 극단적인 사례 3: 깨지기 쉬운 테스트
4.4.5 이상적인 테스트를 찾아서: 결론
4.5 대중적인 테스트 자동화 개념 살펴보기
4.5.1 테스트 피라미드 분해
4.5.2 블랙박스 테스트와 화이트박스 테스트 간의 선택
요약
5장. 목과 테스트 취약성
5.1 목과 스텁 구분
5.1.1 테스트 대역 유형
5.1.2 도구로서의 목과 테스트 대역으로서의 목
5.1.3 스텁으로 상호 작용을 검증하지 말라
5.1.4 목과 스텁 함께 쓰기
5.1.5 목과 스텁은 명령과 조회에 어떻게 관련돼 있는가
5.2 식별할 수 있는 동작과 구현 세부 사항
5.2.1 식별할 수 있는 동작은 공개 API와 다르다
5.2.2 구현 세부 사항 유출: 연산의 예
5.2.3 잘 설계된 API와 캡슐화
5.2.4 구현 세부 사항 유출: 상태의 예
5.3 목과 테스트 취약성 간의 관계
5.3.1 육각형 아키텍처 정의
5.3.2 시스템 내부 통신과 시스템 간 통신
5.3.3 시스템 내부 통신과 시스템 간 통신의 예
5.4 단위 테스트의 고전파와 런던파 재고
5.4.1 모든 프로세스 외부 의존성을 목으로 해야 하는 것은 아니다
5.4.2 목을 사용한 동작 검증
요약
6장. 단위 테스트 스타일
6.1 단위 테스트의 세 가지 스타일
6.1.1 출력 기반 테스트 정의
6.1.2 상태 기반 스타일 정의
6.1.3 통신 기반 스타일 정의
6.2 단위 테스트 스타일 비교
6.2.1 회귀 방지와 피드백 속도 지표로 스타일 비교하기
6.2.2 리팩터링 내성 지표로 스타일 비교하기
6.2.3 유지 보수성 지표로 스타일 비교하기
6.2.4 스타일 비교하기: 결론
6.3 함수형 아키텍처 이해
6.3.1 함수형 프로그래밍이란?
6.3.2 함수형 아키텍처란?
6.3.3 함수형 아키텍처와 육각형 아키텍처 비교
6.4 함수형 아키텍처와 출력 기반 테스트로 전환
6.4.1 감사 시스템 소개
6.4.2 테스트를 파일 시스템에서 분리하기 위한 목 사용
6.4.3 함수형 아키텍처로 리팩터링하기
6.4.4 예상되는 추가 개발
6.5 함수형 아키텍처의 단점 이해하기
6.5.1 함수형 아키텍처 적용 가능성
6.5.2 성능 단점
6.5.3 코드베이스 크기 증가
요약
7장. 가치 있는 단위 테스트를 위한 리팩터링
7.1 리팩터링할 코드 식별하기
7.1.1 코드의 네 가지 유형
7.1.2 험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기
7.2 가치 있는 단위 테스트를 위한 리팩터링하기
7.2.1 고객 관리 시스템 소개
7.2.2 1단계: 암시적 의존성을 명시적으로 만들기
7.2.3 2단계: 애플리케이션 서비스 계층 도입
7.2.4 3단계: 애플리케이션 서비스 복잡도 낮추기
7.2..5 4단계: 새 Company 클래스 소개
7.3 최적의 단위 테스트 커버리지 분석
7.3.1 도메인 계층과 유틸리티 코드 테스트하기
7.3.2 나머지 세 사분면에 대한 코드 테스트하기
7.3.3 전제 조건을 테스트해야 하는가?
7.4 컨트롤러에서 조건부 로직 처리
7.4.1 CanExecute / Execute 패턴 사용
7.4.2 도메인 이벤트를 사용해 도메인 모델 변경 사항 추적
7.5 결론
요약
3부. 통합 테스트
8장. 통합 테스트를 하는 이유
8.1 통합 테스트는 무엇인가?
8.1.1 통합 테스트의 역할
8.1.2 다시 보는 테스트 피라미드
8.1.3 통합 테스트와 빠른 실패
8.2 어떤 프로세스 외부 의존성을 직접 테스트해야 하는가
8.2.1 프로세스 외부 의존성의 두 가지 유형
8.2.2 관리 의존성이면서 비관리 의존성인 프로세스 외부 의존성 다루기
8.2.3 통합 테스트에서 실제 데이터베이스를 사용할 수 없으면 어떻게 할까?
8.3 통합 테스트: 예제
8.3.1 어떤 시나리오를 테스트할까?
8.3.2 데이터베이스와 메시지 버스 분류하기
8.3.3 엔드 투 엔드 테스트는 어떤가?
8.3.4 통합 테스트: 첫 번째 시도
8.4 의존성 추상화를 위한 인터페이스 사용
8.4.1 인터페이스와 느슨한 결합
8.4.2 프로세스 외부 의존성에 인터페이스를 사용하는 이유는 무엇인가?
8.4.3 프로세스 내부 의존성을 위한 인터페이스 사용
8.5 통합 테스트 모범 사례
8.5.1 도메인 모델 경계 명시하기
8.5.2 계층 수 줄이기
8.5.3 순환 의존성 제거하기
8.5.4 테스트에서 다중 실행 구절 사용
8.6 로깅 기능을 테스트하는 방법
8.6.1 로깅을 테스트해야 하는가?
8.6.2 로깅을 어떻게 테스트해야 하는가?
8.6.3 로깅이 얼마나 많으면 충분한가?
8.6.4 로거 인스턴스를 어떻게 전달하는가?
8.7 결론
요약
9장. 목 처리에 대한 모범 사례
9.1 목의 가치를 극대화하기
9.1.1 시스템 끝에서 상호 작용 검증하기
9.1.2 목을 스파이로 대체하기
9.1.3 IDomainLogger는 어떤가?
9.2 목 처리에 대한 모범 사례
9.2.1 목은 통합 테스트만을 위한 것
9.2.2 테스트당 목이 하나일 필요는 없음
9.2.3 호출 횟수 검증하기
9.2.4 보유 타입만 목으로 처리하기
요약
10장. 데이터베이스 테스트
10.1 데이터베이스 테스트를 위한 전제 조건
10.1.1 데이터베이스를 형상 관리 시스템에 유지
10.1.2 참조 데이터도 데이터베이스 스키마다
10.1.3 모든 개발자를 위한 별도의 데이터베이스 인스턴스
10.1.4 상태 기반 데이터베이스 배포와 마이그레이션 기반 데이터베이스 배포
10.2 데이터베이스 트랜잭션 관리
10.2.1 제품 코드에서 데이터베이스 트랜잭션 관리하기
10.2.2 통합 테스트에서 데이터베이스 트랜잭션 관리하기
10.3 테스트 데이터 생명 주기
10.3.1 병렬 테스트 실행과 순차적 테스트 실행
10.3.2 테스트 실행 간 데이터 정리
10.3.3 인메모리 데이터베이스 피하기
10.4 테스트 구절에서 코드 재사용하기
10.4.1 준비 구절에서 코드 재사용하기
10.4.2 실행 구절에서 코드 재사용하기
10.4.3 검증 구절에서 코드 재사용하기
10.4.4 테스트가 데이터베이스 트랜잭션을 너무 많이 생성하는가?
10.5 데이터베이스 테스트에 대한 일반적인 질문
10.5.1 읽기 테스트를 해야 하는가?
10.5.2 리포지터리 테스트를 해야 하는가?
10.6 결론
요약
4부. 단위 테스트 안티 패턴
11장. 단위 테스트 안티 패턴
11.1 비공개 메서드 단위 테스트
11.1.1 비공개 메서드와 테스트 취약성
11.1.2 비공개 메서드와 불필요한 커버리지
11.1.3 비공개 메서드 테스트가 타당한 경우
11.2 비공개 상태 노출
11.3 테스트로 유출된 도메인 지식
11.4 코드 오염
11.5 구체 클래스를 목으로 처리하기
11.6 시간 처리하기
11.6.1 앰비언트 컨텍스트로서의 시간
11.6.2 명시적 의존성으로서의 시간
11.7 결론
요약
1장. 단위 테스트 목표
1.1 단위 테스트 현황
1.2 단위 테스트 목표
1.2.1 좋은 테스트와 좋지 않은 테스트를 가르는 요인
1.3 테스트 스위트 품질 측정을 위한 커버리지 지표
1.3.1 코드 커버리지 지표에 대한 이해
1.3.2 분기 커버리지 지표에 대한 이해
1.3.3 커버리지 지표에 관한 문제점
1.3.4 특정 커버리지 숫자를 목표로 하기
1.4 무엇이 성공적인 테스트 스위트를 만드는가?
1.4.1 개발 주기에 통합돼 있음
1.4.2 코드베이스에서 가장 중요한 부분만을 대상으로 함
1.4.3 최소 유지비로 최대 가치를 끌어냄
1.5 이 책을 통해 배우는 것
요약
2장. 단위 테스트란 무엇인가
2.1 ‘단위 테스트’의 정의
2.1.1 격리 문제에 대한 런던파의 접근
2.1.2 격리 문제에 대한 고전파의 접근
2.2 단위 테스트의 런던파와 고전파
2.2.1 고전파와 런던파가 의존성을 다루는 방법
2.3 고전파와 런던파 비교
2.3.1 한 번에 한 클래스만 테스트하기
2.3.2 상호 연결된 클래스의 큰 그래프를 단위 테스트하기
2.3.3 버그 위치 정확히 찾아내기
2.3.4 고전파와 런던파 사이의 다른 차이점
2.4 두 분파의 통합 테스트
2.4.1 통합 테스트의 일부인 엔드 투 엔드 테스트
요약
3장. 단위 테스트 구조
3.1 단위 테스트를 구성하는 방법
3.1.1 AAA 패턴 사용
3.1.2 여러 개의 준비, 실행, 검증 구절 피하기
3.1.3 테스트 내 if 문 피하기
3.1.4 각 구절은 얼마나 커야 하는가?
3.1.5 검증 구절에는 검증문이 얼마나 있어야 하는가
3.1.6 종료 단계는 어떤가
3.1.7 테스트 대상 시스템 구별하기
3.1.8 준비, 실행, 검증 주석 제거하기
3.2 xUnit 테스트 프레임워크 살펴보기
3.3 테스트 간 테스트 픽스처 재사용
3.3.1 테스트 간의 높은 결합도는 안티 패턴이다
3.3.2 테스트 가독성을 떨어뜨리는 생성자 사용
3.3.3 더 나은 테스트 픽스처 재사용법
3.4 단위 테스트 명명법
3.4.1 단위 테스트 명명 지침
3.4.2 예제: 지침에 따른 테스트 이름 변경
3.5 매개변수화된 테스트 리팩터링하기
3.5.1 매개변수화된 테스트를 위한 데이터 생성
3.6 검증문 라이브러리를 사용한 테스트 가독성 향상
요약
2부. 개발자에게 도움이 되는 테스트 만들기
4장. 좋은 단위 테스트의 4대 요소
4.1 좋은 단위 테스트의 4대 요소 자세히 살펴보기
4.1.1 첫 번째 요소: 회귀 방지
4.1.2 두 번째 요소: 리팩터링 내성
4.1.3 무엇이 거짓 양성의 원인인가?
4.1.4 구현 세부 사항 대신 최종 결과를 목표로 하기
4.2 첫 번째 특성과 두 번째 특성 간의 본질적인 관계
4.2.1 테스트 정확도 극대화
4.2.2 거짓 양성과 거짓 음성의 중요성: 역학 관계
4.3 세 번째 요소와 네 번째 요소: 빠른 피드백과 유지 보수성
4.4 이상적인 테스트를 찾아서
4.4.1 이상적인 테스트를 만들 수 있는가?
4.4.2 극단적인 사례 1: 엔드 투 엔드 테스트
4.4.3 극단적인 사례 2: 간단한 테스트
4.4.4 극단적인 사례 3: 깨지기 쉬운 테스트
4.4.5 이상적인 테스트를 찾아서: 결론
4.5 대중적인 테스트 자동화 개념 살펴보기
4.5.1 테스트 피라미드 분해
4.5.2 블랙박스 테스트와 화이트박스 테스트 간의 선택
요약
5장. 목과 테스트 취약성
5.1 목과 스텁 구분
5.1.1 테스트 대역 유형
5.1.2 도구로서의 목과 테스트 대역으로서의 목
5.1.3 스텁으로 상호 작용을 검증하지 말라
5.1.4 목과 스텁 함께 쓰기
5.1.5 목과 스텁은 명령과 조회에 어떻게 관련돼 있는가
5.2 식별할 수 있는 동작과 구현 세부 사항
5.2.1 식별할 수 있는 동작은 공개 API와 다르다
5.2.2 구현 세부 사항 유출: 연산의 예
5.2.3 잘 설계된 API와 캡슐화
5.2.4 구현 세부 사항 유출: 상태의 예
5.3 목과 테스트 취약성 간의 관계
5.3.1 육각형 아키텍처 정의
5.3.2 시스템 내부 통신과 시스템 간 통신
5.3.3 시스템 내부 통신과 시스템 간 통신의 예
5.4 단위 테스트의 고전파와 런던파 재고
5.4.1 모든 프로세스 외부 의존성을 목으로 해야 하는 것은 아니다
5.4.2 목을 사용한 동작 검증
요약
6장. 단위 테스트 스타일
6.1 단위 테스트의 세 가지 스타일
6.1.1 출력 기반 테스트 정의
6.1.2 상태 기반 스타일 정의
6.1.3 통신 기반 스타일 정의
6.2 단위 테스트 스타일 비교
6.2.1 회귀 방지와 피드백 속도 지표로 스타일 비교하기
6.2.2 리팩터링 내성 지표로 스타일 비교하기
6.2.3 유지 보수성 지표로 스타일 비교하기
6.2.4 스타일 비교하기: 결론
6.3 함수형 아키텍처 이해
6.3.1 함수형 프로그래밍이란?
6.3.2 함수형 아키텍처란?
6.3.3 함수형 아키텍처와 육각형 아키텍처 비교
6.4 함수형 아키텍처와 출력 기반 테스트로 전환
6.4.1 감사 시스템 소개
6.4.2 테스트를 파일 시스템에서 분리하기 위한 목 사용
6.4.3 함수형 아키텍처로 리팩터링하기
6.4.4 예상되는 추가 개발
6.5 함수형 아키텍처의 단점 이해하기
6.5.1 함수형 아키텍처 적용 가능성
6.5.2 성능 단점
6.5.3 코드베이스 크기 증가
요약
7장. 가치 있는 단위 테스트를 위한 리팩터링
7.1 리팩터링할 코드 식별하기
7.1.1 코드의 네 가지 유형
7.1.2 험블 객체 패턴을 사용해 지나치게 복잡한 코드 분할하기
7.2 가치 있는 단위 테스트를 위한 리팩터링하기
7.2.1 고객 관리 시스템 소개
7.2.2 1단계: 암시적 의존성을 명시적으로 만들기
7.2.3 2단계: 애플리케이션 서비스 계층 도입
7.2.4 3단계: 애플리케이션 서비스 복잡도 낮추기
7.2..5 4단계: 새 Company 클래스 소개
7.3 최적의 단위 테스트 커버리지 분석
7.3.1 도메인 계층과 유틸리티 코드 테스트하기
7.3.2 나머지 세 사분면에 대한 코드 테스트하기
7.3.3 전제 조건을 테스트해야 하는가?
7.4 컨트롤러에서 조건부 로직 처리
7.4.1 CanExecute / Execute 패턴 사용
7.4.2 도메인 이벤트를 사용해 도메인 모델 변경 사항 추적
7.5 결론
요약
3부. 통합 테스트
8장. 통합 테스트를 하는 이유
8.1 통합 테스트는 무엇인가?
8.1.1 통합 테스트의 역할
8.1.2 다시 보는 테스트 피라미드
8.1.3 통합 테스트와 빠른 실패
8.2 어떤 프로세스 외부 의존성을 직접 테스트해야 하는가
8.2.1 프로세스 외부 의존성의 두 가지 유형
8.2.2 관리 의존성이면서 비관리 의존성인 프로세스 외부 의존성 다루기
8.2.3 통합 테스트에서 실제 데이터베이스를 사용할 수 없으면 어떻게 할까?
8.3 통합 테스트: 예제
8.3.1 어떤 시나리오를 테스트할까?
8.3.2 데이터베이스와 메시지 버스 분류하기
8.3.3 엔드 투 엔드 테스트는 어떤가?
8.3.4 통합 테스트: 첫 번째 시도
8.4 의존성 추상화를 위한 인터페이스 사용
8.4.1 인터페이스와 느슨한 결합
8.4.2 프로세스 외부 의존성에 인터페이스를 사용하는 이유는 무엇인가?
8.4.3 프로세스 내부 의존성을 위한 인터페이스 사용
8.5 통합 테스트 모범 사례
8.5.1 도메인 모델 경계 명시하기
8.5.2 계층 수 줄이기
8.5.3 순환 의존성 제거하기
8.5.4 테스트에서 다중 실행 구절 사용
8.6 로깅 기능을 테스트하는 방법
8.6.1 로깅을 테스트해야 하는가?
8.6.2 로깅을 어떻게 테스트해야 하는가?
8.6.3 로깅이 얼마나 많으면 충분한가?
8.6.4 로거 인스턴스를 어떻게 전달하는가?
8.7 결론
요약
9장. 목 처리에 대한 모범 사례
9.1 목의 가치를 극대화하기
9.1.1 시스템 끝에서 상호 작용 검증하기
9.1.2 목을 스파이로 대체하기
9.1.3 IDomainLogger는 어떤가?
9.2 목 처리에 대한 모범 사례
9.2.1 목은 통합 테스트만을 위한 것
9.2.2 테스트당 목이 하나일 필요는 없음
9.2.3 호출 횟수 검증하기
9.2.4 보유 타입만 목으로 처리하기
요약
10장. 데이터베이스 테스트
10.1 데이터베이스 테스트를 위한 전제 조건
10.1.1 데이터베이스를 형상 관리 시스템에 유지
10.1.2 참조 데이터도 데이터베이스 스키마다
10.1.3 모든 개발자를 위한 별도의 데이터베이스 인스턴스
10.1.4 상태 기반 데이터베이스 배포와 마이그레이션 기반 데이터베이스 배포
10.2 데이터베이스 트랜잭션 관리
10.2.1 제품 코드에서 데이터베이스 트랜잭션 관리하기
10.2.2 통합 테스트에서 데이터베이스 트랜잭션 관리하기
10.3 테스트 데이터 생명 주기
10.3.1 병렬 테스트 실행과 순차적 테스트 실행
10.3.2 테스트 실행 간 데이터 정리
10.3.3 인메모리 데이터베이스 피하기
10.4 테스트 구절에서 코드 재사용하기
10.4.1 준비 구절에서 코드 재사용하기
10.4.2 실행 구절에서 코드 재사용하기
10.4.3 검증 구절에서 코드 재사용하기
10.4.4 테스트가 데이터베이스 트랜잭션을 너무 많이 생성하는가?
10.5 데이터베이스 테스트에 대한 일반적인 질문
10.5.1 읽기 테스트를 해야 하는가?
10.5.2 리포지터리 테스트를 해야 하는가?
10.6 결론
요약
4부. 단위 테스트 안티 패턴
11장. 단위 테스트 안티 패턴
11.1 비공개 메서드 단위 테스트
11.1.1 비공개 메서드와 테스트 취약성
11.1.2 비공개 메서드와 불필요한 커버리지
11.1.3 비공개 메서드 테스트가 타당한 경우
11.2 비공개 상태 노출
11.3 테스트로 유출된 도메인 지식
11.4 코드 오염
11.5 구체 클래스를 목으로 처리하기
11.6 시간 처리하기
11.6.1 앰비언트 컨텍스트로서의 시간
11.6.2 명시적 의존성으로서의 시간
11.7 결론
요약
추천사
그렉 라이트(카이노스 소프트웨어)
"없어서는 안 될 자료다."
마크 네나도프(보더커넥트)
"아무리 경험이 많다고 하더라도 집중해서 테스트를 잘하려면 격려의 역할을 하는 무언가가 필요하다."
코너 레드몬드(인컴 프로덕트 컨트롤)
"20년 전 소프트웨어 개발 경력을 시작했을 때 이 책이 있었으면 좋았을 텐데."
제레미 랭
"오랫동안 기다려온 단위 테스트에 관한 책이다."
출판사 서평
◈ 이 책에서 다루는 내용 ◈
◆ 단위 테스트를 평가하기 위한 범용 지침
◆ 안티 패턴을 식별하고 피하기 위한 테스트 기법
◆ 제품 코드와 테스트 코드를 위한 리팩터링 기법
◆ 전체 시스템을 검증하기 위한 통합 테스트 사용법
◈ 이 책의 목표와 대상 독자 ◈
대부분의 온라인 자료나 인쇄물에는 한 가지 단점이 있다. 단위 테스트의 기본에 중점을 두지만 그 이상은 다루지 않는다. 이러한 자료에도 많은 가치가 있지만, 거기서 학습이 끝나지는 않는다. 테스트 작성뿐만 아니라 노력 대비 최상의 결과를 얻을 수 있는 방법을 사용하는 다음... 더보기
◆ 단위 테스트를 평가하기 위한 범용 지침
◆ 안티 패턴을 식별하고 피하기 위한 테스트 기법
◆ 제품 코드와 테스트 코드를 위한 리팩터링 기법
◆ 전체 시스템을 검증하기 위한 통합 테스트 사용법
◈ 이 책의 목표와 대상 독자 ◈
대부분의 온라인 자료나 인쇄물에는 한 가지 단점이 있다. 단위 테스트의 기본에 중점을 두지만 그 이상은 다루지 않는다. 이러한 자료에도 많은 가치가 있지만, 거기서 학습이 끝나지는 않는다. 테스트 작성뿐만 아니라 노력 대비 최상의 결과를 얻을 수 있는 방법을 사용하는 다음... 더보기
Klover 리뷰 (0)
북로그 리뷰 (0) 쓰러가기
북로그 리뷰는 본인 인증 후 작성 가능합니다.
책이나 타인에 대해 근거 없이 비방을 하거나 타인의 명예를 훼손할 수 있는 내용은 비공개 처리 될 수 있습니다.
※ 북로그 리뷰 리워드 제공 2021. 4. 1 종료
책이나 타인에 대해 근거 없이 비방을 하거나 타인의 명예를 훼손할 수 있는 내용은 비공개 처리 될 수 있습니다.
※ 북로그 리뷰 리워드 제공 2021. 4. 1 종료
문장수집 (0) 문장수집 쓰기 나의 독서기록 보기
※구매 후 문장수집 작성 시, 리워드를 제공합니다.
안내
교환/반품/품절안내
※ 상품 설명에 반품/교환 관련한 안내가 있는 경우 그 내용을 우선으로 합니다. (업체 사정에 따라 달라질 수 있습니다.)
| 반품/교환방법 | 마이룸 > 주문관리 > 주문/배송내역 > 주문조회 > 반품/교환신청 , [1:1상담>반품/교환/환불] 또는 고객센터 (1544-1900) ※ 오픈마켓, 해외배송주문, 기프트 주문시 [1:1상담>반품/교환/환불] 또는 고객센터 (1544-1900) |
|---|---|
| 반품/교환가능 기간 | 변심반품의 경우 수령 후 7일 이내, 상품의 결함 및 계약내용과 다를 경우 문제점 발견 후 30일 이내 |
| 반품/교환비용 | 변심 혹은 구매착오로 인한 반품/교환은 반송료 고객 부담 |
| 반품/교환 불가 사유 |
|
| 상품 품절 | 공급사(출판사) 재고 사정에 의해 품절/지연될 수 있으며, 품절 시 관련 사항에 대해서는 이메일과 문자로 안내드리겠습니다. |
| 소비자 피해보상 환불지연에 따른 배상 |
|
기프트 BEST
![[1+1] 리큅 무선 온열 목안마기 넥닥터 LNR-1902W](http://image.kyobobook.co.kr/newimages/giftshop_new/goods/400/1967/hot1648091253125.jpg)
![[동원] 동원샘물 웨이크업뷰티 500ml*20병](http://image.kyobobook.co.kr/newimages/giftshop_new/goods/400/1178/hot1655873224720.png)
![[해외]Unit Testing Principles, Practices, and Patterns (Paperback)](http://image.kyobobook.co.kr/images/book/large/277/l9781617296277.jpg)
LG U+ 구매안전서비스
▶서비스 가입 확인
고객님은 안전거래를 위해 현금 등으로 결제시 저희 쇼핑몰에서 가입한 LG유플러스의 구매안전서비스를 이용하실 수 있습니다.
정보보호관리체계
ISMS 인증획득
ISMS 인증획득
[인증범위] 온라인 교보문고 서비스 운영
[유효기간] 2020.11.04. ~ 2023.11.03.
바로가기
