1. Day02
실습으로

2. 배우는

3.
테스트

4. 주도

5. 개발

6.
1

7. 학습목표
u 본 교육과정은 실습을 통해 TDD를 배워보는 과정입니다.
u TDD 그 자체가 목적이 아니며, 효율적인 프로그래밍을 위한 과정의 하나로, 올바
른 개발 스타일을 몸에 익히는 것이 이번 교육의 목적입니다.
2
디자인패턴

8.
1. 코드개선
1. 객체지향 특징
2. 코드 개선 [실습]
3
디자인패턴

9. Learning concept
- Wisdom over Knowledge
- Practice over Seeing
- I don’t know what I don’t know
- options and guide for good TDD
4

10. 과정 진행 키워드: 3C
Consideration
Communication
Cooperation
5

11. 첫째 시간
기초점검
6

12. 환경설정 및 기본코드 작성
개발 환경을 확인합니다.
간단한 코드를 작성해 봅니다.
7

13. 워밍업 연습문제
0에 가까운 숫자 찾기
8

14. 전통적인 개발 진행
문제발생 요구사항 발생
기능구현
Console 에 값 찍어
보기
간단한 테스트
Yes

15.
에러발생?
No

16.
완료!
9

17. 일반적인 개발
1. 특정 모듈의 개발 기간이 길어질수록 개발자의 목표의식이 흐려진다.
“어디까지 짰더라?”
“아, 내가 지금 뭘 하는 거였지?”
“이 모듈이 무슨 기능을 해야 한대더라?”
2. 작업 분량이 늘어날수록 확인이 어려워진다.
“로그가 어디 있더라?”
“이것도 화면으로 출력해보고…”
10

18. 일반적인 개발
3. 개발자의 집중력이 필요해진다.
“앗! 화면 지나갔다!”
4. 논리적인 오류를 찾기가 어렵다.
“여기서 그러니까 이 값이 들어가면 나와야 하는 게… 아… 이게 맞던가?”
5. 코드의 사용 방법과 변경 이력을 개발자의 기억력에 의존하게 되는 경우가 많다.
“맞아! 개인고객 인증을 고치면 법인 고객인증 부분도 함께 고쳤어야 했었지!!”
6. 테스트 케이스가 적혀 있는 엑셀 파일을 보며 매번 테스트를 실행하는 게 점점 귀찮아져서
는 점차 간소화하는 항목들이 늘어난다.
“날짜? 1111. 주민번호? 우선 222222-2222222. 주소? 서울 개똥이네”
11

19. 일반적인 개발
7. 코드 수정 시에 기존 코드의 정상 동작에 대한 보장이 어렵다.
“휴~ 찾았다. 여길 고쳐야 하는 거였군! 아, 근데 이 금칙어 필터 모듈 혹시 다른 데서도 쓰는
거 아냐?”
8. 테스트를 해보려면 소스코드에 변경을 가하는 등, 번거로운 선행 작업이 필요할 수 있다.
“입고 처리를 테스트하려면, 주문이 완료됐다고 테이블에 직접 업데이트를 해줘야…”
9. 그래서 소스 변경 시 해야 하는 회귀 테스트3는 곧잘 희귀 테스트(rare test)가 되기 쉽다.
“아, 그걸 언제 다 다시 테스트해? 우선 급한 불부터 끄고 보자구.
집에 안 갈거야?”
12

20. 좋은 설계를 위한 노력,
좋은 설계자를 만들어 내기 위한 노력
13

21. 객체 지향 기본 원칙
14

22. OCP
SRP
ISP
Demeter’s Law (=Hollywood law)
IOC
15

23. 다음 두 코드 중 더 나은 디자인은?
Case.1

24. class

25. Rental

26. {

31. Movie

32. movie;

37. Rental(Service

38. service)

39. {

48. this.movie

49. =

50. service.getMovie();

55. }

56.
}

57.
Case.2

58. class

59. Rental

60. {

65. Movie

66. movie;

71. Rental(Movie

72. movie)

73. {

82. this.movie

83. =

84. movie;

89. }

90.
}

92. (based on my five years of experience)
Strongly recommended approach #1
테스트 주도 개발
Test-Driven Development
17

93. 기원 Origin
애자일(agile) 개발방식 중 하나인 XP의
실천방법 중 하나
18

94. TDD의 기본
“프로그램을 작성하기 전에 테스트 먼저 하라!”
Test the program before you write it.

95.
“잘 동작하는 깔끔한 코드”
Clean code that works

96.
“질문 à 응답 à 정제 à 반복”
Ask à Respond à Refine à Repeat

97.
19

98. Test Driven Development Cycle
q 질문 Ask : 테스트를 작성함으로써 시스템에 질문한다.
(FAIL)
q 응답 Respond : 테스트를 통과하는 코드를 작성해서 질문에 대답한다.
(PASS)
q 정제 Refine : 아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은
명확히 해서 대답을 정제한다. (REFACTORING)
q 반복 Repeat : 다음 질문을 통해 대화를 계속 진행한다.
20

99. 코딩 시연
21

100. 몇 가지 설문
22

101. 어떤 애자일 기법을 적용하고 있습니까?
관리 기법을 제외한 개발 테크닉으로만 순위를 뽑아보면 다음과 같다.
1위: 단위 테스트(Unit Testing)
2위: 지속적인 통합(Continuous Integration)
3위: 자동화된 빌드(Automated Builds)
4위: 테스트 주도 개발(TDD)
5위: 짝 프로그래밍(Pair Programming)
2009년 7월부터 12월까지 88개국 총 2570명을 대상으로 조사한 결과다.
23

102. 70%
38%
24

103. 가장 큰 효과를 봤던 Agile 기법
CI와 일일 스탠드업 미팅, TDD
가장 배우기 어려웠던 Agile 기법
개발/인수 TDD, 짝 프로그래밍
25

104. Start Test with JUnit
1. xUnit Test Frmawork 중 하나
2. Text base 혹은 GUI(Swing) base 로 구동됨
3. xUnit Style을 따른다.
assert (예상값, 실제값)
4. 결과는 성공:녹색/실패:붉은색 중 하나로 표시
26

105. JUnit Assertions
- assertEquals( [message], expected, actual)
- assertTrue( [message], expected ) / assertFalse( [message],
expected )
- assertNull( [message], expected ) / assertNotNull( [message],
expected)
- fail( [message] )
27

106. Sample Practice
q Account Class
- 계좌 잔고 조회
- 입금/출금
- 예상 복리 이자 (추가 개발)
28

107. Outlook
1. 정형화된

108. 형태의

109. 테스트를

110. 작성함으로써

111. 테스트

112. 과정을

113. 자동화한다.

114.
2. 테스트

115. 결과를

116. 즉시

117. 알

118. 수

119. 있다.

121.
3. 개발하는

122. 시점

123. 이후로도

124. 지속적인

125. 테스트가

126. 보장되며

127.
4. 이를

128. 통해

129. 전체

130. 프로젝트의

131. 안정성에

132. 크게

133. 기여한다.

135.
5. 이러한

136. 모든

137. 과정이

138. 개발자에게

139. 짐이

140. 되는

141. 것이

142. 아니라

143. 즐거운

144. 커뮤니케이션의

145.
수단이

146. 된다

147.
29

148. 품질
(Quality Assurance Problem)
30

149. 품질을 어떻게 높을 것인가?
어느 정도 속도로 개발을 진행할 것인가?
31

150. 테스트 주도 개발을 통한
품질 향상 실체화 연구
출처 : 테스트 주도 개발을 통한 품질 향상 실체화: 업계 개발팀 네 팀들에 대한 적용 결과와 경
험들 (Nachiappan Nagappan E. Michael Maximilien Thirumalesh Bhat Laurie
Williams)
32

151. 단점은?
33

152. 어려운 비교
결함발생 10% 증가
개발기간 10% 증가
선택은?
34

153. 잠깐….
35

154. Expertise
Experience
Divide Conquer
Co-operation

155. 잘하면 고효율, 못하면 가문의 원수가 되는
짝 프로그래밍
Effective Pair Programming
37

156. 짝 프로그래밍
(Pair Programming)
38

157. Give 효율!
Take 성장감!
39

158. 결함감소율
15% ~ 50%
40

159. 고려사항
- 개발자(설계자)의 스킬
- 업무 난이도
- 작업 시간이 더 걸릴 수 있다
41

160. 혼자 할 때 보다
Pair Programming 으로 할 때에
업무가 더 즐거웠습니까?
출처
Factors Affecting the Perceived Effectiveness of
Pair Programming in Higher Education
42

161. Comments
우리가 하루에 절반 이상을 쏟아 붓는 ‘일’이 재밌어 진다고 한다면,
효율을 떠나서 그것만큼 즐거울 일이 또 있을까요? 즐겁게 일하고 월급도 나온대요!!
43

162. 혼자 할 때 보다
Pair Programming 으로 할 때에
더 많이 배웠다고 생각합니까?
44

163. 45

164. 짝 프로그래밍의 성공 조건
46

165. 짝 프로그래밍은
둘이 함께 같은 업무를 개발 하는 것이다?
47

166. 99% Fail!!

167. 요령과 발생할 수 있는 문제점,
그리고 대처 방식을 사전에 알려주어야 함
49

168. Comments
네비게이터 네비게이터는 개발의 방향을 주도하
는 사람입니다. 속칭 ‘브레인’에 해당
하는 셈이죠. 드라이버를 움직이는
인물이기도 하죠. 때때로 내 맘 같지
않은 답답한 마음에 운전대를 뺏고
싶을 때가 종종 있을테지만, 그러면
안됩니다.
여정을 같이 하는 동료를 인내하고
신뢰해 주세요. 조금 돌아가면 어때
요? 서로를 이해하고 새로운 교훈을
받아 들일 자세가 되어 있다면 여정
은 즐거운 여행이 될 수 있습니다.
드라이버
Comments
드라이버는 네비게이터의 의견대로 개발을 진행해 나가는 사
람입니다. 자발적인 의지로 개발을 지휘한다기 보다는 최대한
네비게이터를 믿고 따라 줍니다. 물론 자신의 경험과 스킬을
기반으로 끊임없이 네비게이터와 대화하고 질문하고 의도를
파악해 나갑니다.
50

169. - 명시적인 역할 전환
- 오래 한 역할을 하지 않을 것!
- 둘 다 편안한 자세를 잡을 것!

170. 고려사항
- 개발자(설계자)의 스킬
- 업무 난이도
- 작업 시간이 더 걸릴 수 있다

171. 효율 높았던 경우
- 프로젝트 초반
- 창의성이 요하거나 어려운 업무
- 신입 팀원을 적응 시킬때

172. Do
- 상대방에 대한 존중
- 개발 업무의 목표를 잊지 않을 것

173. Don’t
- 짜증
- 100분 토론
Q 짜증의 표현에는 또 어떤 것들이 있을까요?

174. 실패 케이스들

175. 자존심 대결

176. 마이크로 컨트롤

177. Too easy or Too Hard

178. 성공 케이스
- 오월동주(吳越同⾈舟)
- 후배 키우기 혹은 업무 백업
- 챙겨주기는 문화 즐겁게 일하기
= 좋은 팀웍!

179. 잘되면 짝 설계까지도 도전!
Simpler,
More-maintainable
and
catch design defects early

180. 네 번째 시간
TDD 작성패턴
TDD workshop by Pair Programming
62

181. TDD 작성 기본 원칙
- 실패하는 테스트를 작성하기 전에는 절대로
제품 코드를 작성하지 않는다.
- 실패하는 테스트 코드를 한 번에 하나
이상 만들지 않는다.
- 현재 실패하고 있는 테스트를 통과하기에
충분한 정도를 넘어서는 코드는 작성하지 않는다.
63

182. 64

183. 65

184. 66

185. 67

186. 다섯 번째 시간
짝 TDD실습
TDD workshop by Pair Programming
68

187. 자판기 잔돈 계산
- 최소 개수의 동전으로 잔돈을 돌려준다.
예) 1000원 넣고 650원짜리 음료를 선택했다면,
잔돈은 100, 100, 100, 50 원으로 반환한다.
- 지폐를 잔돈으로 반환하는 경우는
없다고 가정한다.
69

188. 여섯 번째 시간
TDD고급
Advanced Technic of TDD
70

189. Mock Object
모의 객체(Mock Object)
- 의존성을 분리하기 위해서
만드는 가짜 객체
71

190. Mock Object
모의 객체를 사용하는 경우
- 테스트 작성을 위한 환경 구축이 어려워서
- 테스트가 특정 경우나 순간에 의존적이라
- 테스트 시간이 오래 걸려서
72

191. Mock Object
테스트 더블(Test Double)
- dummy
- stub
- fake
- spy
- Mock
73

192. 테스트 더블 - Dummy
겨우 컴파일만 되는 바보 객체
74

193. 테스트 더블 - Stub
특정 상태를 대표해서 동작하는 객체
75

194. 테스트 더블 - Fake
일부 기능성 로직이 들어가 있는 객체
76

195. 테스트 더블 - Spy
객체의 내부 상태를 기록해 주는 객체
77

196. 테스트 더블 - Mock
객체의 내부 상태뿐 아니라 동작까지도
감시할 수 있게 만든 객체
78

197. 실습
모의 객체를 이용한 테스트 작성
79

198. Mockito
CreateMock
인터페이스에 해당하는 Mock 객체를 만든다.
Stub
테스트에 필요한 Mock 객체의 동작을 지정한다
(단, 필요 시에만).
Exercise
테스트 메소드 내에서 Mock 객체를 사용한다.
Verify
메소드가 예상대로 호출됐는지 검증한다.
80

199. Mockito
행위 기반 테스트
81

200. Mockito
Stub 테스트
82

201. QA
83

202. 실습 – 모바일 교통카드
- 장비 : 핸드폰, 단말기
- GPS 및 JVM 탑재되어 있음
- 네트워크 통신은 고려하지 않음
84

203. 요금체계 – 모바일 교통카드
기본 요금
대상 요금
일반 900원
청소년 720원
초등학생 450원
85

204. 추가요금 - 모바일 교통카드
버스
기본요금 이외의 추가요금 없음
지하철
10km초과 ~40km까지 : 5km 마다 100원
40km초과시 : 10km 마다 100원
* 단, 환승은 고려하지 않는다.
86

205. 거리계산 – 모바일 교통카드
서울시청
(4, 5)
거리
= SQRT(3*3 + 4*4)
= 5 km
여의도역
(1, 1)
87

206. 개발목표
No1. 최대한 빠른 시간 내에
No2. 가급적 정확히
No3. 확장을 고려?
88