개발자를 위한 시프트-레프트 테스트

옮긴이 머리말 xiii
베타리더 후기 xv
머리말 xviii
이 책에 대하여 xxii

CHAPTER 1 테스트 시작하기 1
1.1 시프트-레프트의 개요 3
1.2 애자일에서의 품질 7
__1.2.1 애자일 테스트란 8

CHAPTER 2 시프트-레프트 테스트 13
2.1 시프트-레프트 모델 16
2.2 시프트-레프트 테스트의 특징 17
__2.2.1 시프트-레프트와 출시 후 품질 18
__2.2.2 시프트-레프트와 남은 버그의 리스크 20
2.3 마치며 23

CHAPTER 3 개발자 테스트의 기본 중 기본 25
3.1 개발자가 반드시 알아야 할 테스트 기법 29
__3.1.1 경곗값 테스트 30
__3.1.2 상태 전이 테스트 33

CHAPTER 4 코드 기반 단위 테스트 37
4.1 코드 기반 단위 테스트 40
4.2 명령 커버리지(C0) 41
4.3 조건 커버리지(C1) 43
4.4 자주 발생하는 단위 테스트 오류 44
4.5 코드 기반 단위 테스트 작성법 45
__4.5.1 일반적인 테스트 방법(TDD) 46
4.6 커버리지 비율: 코드 기반 단위 테스트의 성패를 측정 50

CHAPTER 5 단위 테스트 효율화: 쉬운 단위 테스트 55
5.1 코드 복잡도 60
5.2 단위 테스트의 대상 62
__5.2.1 단위 테스트할 범위를 선정 64
__5.2.2 독자적인 방법: 파일을 2개로 분리 66
__5.2.3 명확한 장점 68

CHAPTER 6 기능 단위별 단위 테스트 75
6.1 개발자가 확인할 단위 기능 테스트 77
__6.1.1 정렬 기능의 단위 테스트 78
6.2 블랙박스 테스트와 화이트박스 테스트 83

CHAPTER 7 리팩터링 87
7.1 단위 테스트가 어려운 복잡한 코드 90
7.2 파일 코드 리팩터링 92
7.3 큰 클래스의 리팩터링 93
__7.3.1 CK 지표 93
7.4 복잡도를 낮추는 리팩터링 98
7.5 출구는 하나 100
7.6 MVC 분리 101

CHAPTER 8 코드 리뷰 107
8.1 코드 리뷰란 109
8.2 페어 프로그래밍 113

CHAPTER 9 통합 테스트 119
9.1 통합 테스트 패턴 121
__9.1.1 통합 테스트 중시 설계 122
9.2 API 테스트와 API 버그 밀도에 관한 사고방식 124
9.3 카오스 엔지니어링 126
__9.3.1 카오스 엔지니어링과 품질 및 생산성 131

CHAPTER 10 시스템 테스트의 자동화 135
10.1 최악의 시스템 테스트 139
10.2 키워드 주도 자동 테스트 142
10.3 망상적 자동화 144

CHAPTER 11 탐색적 테스트 147

CHAPTER 12 테스트 전체 설계 153
12.1 단위 테스트 없이 피폐해지는 조직 156

CHAPTER 13 애자일 및 시프트-레프트 지표 159
13.1 돌연변이 테스트 162
__13.1.1 돌연변이 테스트의 사고방식 164
__13.1.2 변이의 내용 165
__13.1.3 돌연변이 테스트의 문제점 172
__13.1.4 돌연변이 커버리지 비율이라는 사고방식 174
13.2 사용자 스토리와 신뢰성 지표 175
__13.2.1 운영 프로파일 176
13.3 신뢰도 성장 곡선 지표 177

CHAPTER 14 애자일에서의 요구사항 사양 183
14.1 사용자 스토리의 장점 189

CHAPTER 15 개발자 테스트의 실제 샘플 191
15.1 단위 테스트 194
__15.1.1 간단한 애플리케이션 작성 195
__15.1.2 단위 테스트 생성 197
15.2 코드 커버리지 측정 202
__15.2.1 코드 커버리지 도구 준비 202
__15.2.2 가장 간단한 커버리지(명령 커버리지) 203
__15.2.3 조건 커버리지 205

에필로그 208
참고 문헌 211
찾아보기 218

먼저 그림 2.3[IPA17]을 함께 살펴보겠습니다. 일본 IPA(정보처리추진기구)에서 발표한 수치로, 조기 단계에서 품질을 보증하는 편이 출시 후의 품질을 더 높인다고 명확하게 기재되어 있습니다. / 만약 조기 단계에서 85% 이상의 버그를 발견할 수만 있다면, 대부분의 프로젝트에서 큰 폭의 일정 지연이 발생하거나 출시 후에 치명적인 버그가 나타나는 일은 없을 것입니다. 85%의 버그를 검출하는 작업은 단지 올바르게 코딩하는 것만으로는 불가능하며, 요구사항 사양과 설계 단계에서의 버그 검출(올바른 설계에 대한 숙고)을 해야 합니다.

단위 테스트(unit test)의 정의에 관한 역사는 깁니다. 먼저 1970년의 <Managing the Development of Large Software Systems>라는 논문까지 거슬러 올라갑니다(그림 4.1). / 여기에서 말하는 ‘코딩과 단위 테스트’가 단위 테스트에 해당합니다. 하지만 업무를 하다 보면, 단위 기능 테스트(프린트 기능, URL로 점프 기능 등)도 단위 테스트라 부르기도 합니다. 소프트웨어 개발에서 용어 정의는 대단히 중요한 부분인 만큼, 개발을 시작하기 전에 단위 테스트가 코드의 정확성을 확인하는 테스트인지, 혹은 단위 기능에 관한 테스트인지를 명확하게 해야 합니다

‘그렇다면 시스템 테스트의 자동화도 그런 구조로 넣으면 되지 않을까?’라고 생각할 수도 있습니다. 실제로 필자도 넣어봤지만, 셀레늄(Selenium)도 애피움(Appium)도 실행 속도가 너무 느립니다. 게다가 병행해서 실행하려면 수많은 PC나 인스턴스를 실행해야 하고, 실패했을 때 (실제 버그인지, 테스트 코드의 버그인지) 그 원인을 파악하는 데 시간이 걸립니다. / 하지만 만약 함수 단위의 단위 테스트라면, 실행 속도도 빠르고 병렬 테스트도 간단하게 실행할 수 있습니다(그림 8.3).