추가 적립 안내

소프트웨어 품질을 높이기 위한 개발자 테스트 프랙티스

소프트웨어 품질은 조기에 결정되므로 개발 과정에서 테스트를 뒤로 미루지 않고 최대한 앞 단계에서 수행하자는 것이 ‘시프트-레프트’ 접근법이다. 이 책은 이상론처럼 보이는 시프트-레프트를 개발 현장에서 실천하는 방법을 보여준다. 테스트 기초부터, 단위 테스트, 리팩터링, 애자일 개발 시의 품질 담보, 테스트 자동화까지, 경험과 연구에서 비롯된 테스트 기법의 정수를 담았다. 애자일 시대에 맞는 실용적이고 효율적인 개발자 테스트 프랙티스를 내 것으로 만들어보자.

소프트웨어 품질은 조기에 결정된다
버그와 야근을 줄이기 위한 ‘근거 있는’ 효율적 테스트 기법 총정리

개발 과정에서 테스트를 뒤로 미루지 않고 최대한 조기에 수행하자는 ‘시프트-레프트’ 접근법이 있다. 현실과 동떨어진 이상론이라고 생각하는 사람이 많겠지만, 일본에서 소프트웨어 테스트 분야의 일인자로 평가받는 다카하시 주이치는 이 책을 통해 시프트-레프트를 개발 현장에서 실천할 수 있음을 보여준다.

저자는 품질 컨설턴트로서 오랜 세월 축적해온 경험을 바탕으로 테스트 기초 지식부터 경곗값 테스트, 단위 테스트, 시스템 테스트, 리팩터링, 정량화를 통한 애자일 개발 시의 품질 보증, 테스트 효율화 및 자동화까지 오늘날 현장에서 요구되는 테스트의 모든 것을 명료하게 정리했다. 경험뿐만 아니라 각종 연구 결과를 근거로 제시함으로써 객관성도 높였다. 실제 사례를 대화 형태로 재구성해 직관적인 이해를 돕게 배려한 점도 책의 미덕이다.

현장에서 실천할 수 있는 지식에 목말랐던 개발자들에게 단순히 이상론을 설파하는 게 아니라 실천할 방안을 알려준다는 점이 책의 가장 큰 의의가 아닐까 싶다. 일례로 단위 테스트만 해도 못 들어본 개발자는 없겠지만 현실적인 이유로 실천하는 개발자는 많지 않다. 저자는 단위 테스트의 ‘본질’을 설명하고 효율화 기법을 제시함으로써 실천력을 높여준다. 이 책으로 버그와 야근을 줄이기 위한 개발자 테스트 프랙티스를 내 것으로 만들어보자.

주요 내용
■ 조기 품질을 향상하는 시프트-레프트에 대한 이해
■ 경곗값 테스트 등 개발자 테스트 기법의 기초
■ 단위 테스트의 본질, 그리고 효율화를 통한 실천
■ 시스템 테스트 자동화에서의 최악과 최선의 방식
■ 돌연변이 테스트 등 정량화를 통한 품질 보증

옮긴이 머리말 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%의 버그를 검출하는 작업은 단지 올바르게 코딩하는 것만으로는 불가능하며, 요구사항 사양과 설계 단계에서의 버그 검출(올바른 설계에 대한 숙고)을 해야 합니다. (18쪽)

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

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

캡처 & 리플레이 도구는 스크립트의 규모가 커질수록 유지보수성이 떨어집니다. 같은 테스트를 수행하는 스크립트도 함수화되지 않은 채 그저 복사 & 붙여넣기로 가득 차기 때문입니다. 그 결과 복사 & 붙여넣기가 차츰 증가하고, UI를 한 군데만 변경하더라도 모든 스크립트가 작동하지 않는 현상이 발생합니다. / 앞에서 이미 설명한 내용이지만, 단위 테스트와 시스템 테스트 모두 자동화할 때 가장 먼저 고려할 점은 유지보수성입니다. 최초 자동화까지의 속도와 비용에 아무리 메리트가 있다고 해도, 계속해서 자동화할 수 없다면 의미가 없습니다. (141~142쪽)

그림 13.1을 한 번 더 참조해보면 어떤 품질을 달성하고 싶은지, 어떤 정량적인 품질 목표를 세울 것인지, 그리고 그 정량적인 품질 목표에 관해 어떤 테스트를 달성할 것인지가 애자일에서의 대표적인 품질 보증에서 중요하다는 것을 알 수 있습니다. / 따라서 이번 장에서는 애자일에서의 정략적 품질에 관해 설명하겠습니다. 필자가 보기에 애자일에 적합한 대표적인 품질 지표는 다음과 같습니다.
● 코드 커버리지 비율(C0가 아닌 C1)
● 돌연변이 테스트
● CK 지표
● 핫스팟
● 신뢰도 성장 곡선 (162쪽)

먼저 JaCoCo로 조건 커버리지가 확실하게 작동하고 있는지 확인해보겠습니다. 개발자는 ‘명령 커버리지와 조건 커버리지의 차이는 커버리지 비율이 단지 10% 정도 다른 것뿐’이라고 평가하는 경우가 있습니다. 하지만 테스트 담당자에게 명령 커버리지는 품질 보증 관점에서 아무런 도움도 되지 않습니다. 왜냐하면 가장 중요한 테스트 기법인 ‘경곗값 테스트’가 확실히 이루어졌는지를 명령 커버리지로는 판단할 수 없기 때문입니다. / 다소 난폭한 방법이지만, 테스트된 함수가 분기되었는지만 확인하기 위해 테스트할 소스 코드를 리스트 15.3과 같이 변경합니다. 이 코드에서는 분모에 0이 오는 경우, 그대로 return 0으로 빠져나갑니다. (205~206쪽)