TDD&Refactoring Day 02: TDD

1,242 views
1,122 views

Published on

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,242
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

TDD&Refactoring Day 02: TDD

  1. 1. Day02 실습으로
  2. 2.  배우는
  3. 3.   테스트
  4. 4.  주도
  5. 5.  개발
  6. 6.   1  
  7. 7. 학습목표u  본 교육과정은 실습을 통해 TDD를 배워보는 과정입니다.u  TDD 그 자체가 목적이 아니며, 효율적인 프로그래밍을 위한 과정의 하나로, 올바 른 개발 스타일을 몸에 익히는 것이 이번 교육의 목적입니다. 2   디자인패턴
  8. 8.          1. 코드개선 1.  객체지향 특징 2.  코드 개선 [실습] 3   디자인패턴
  9. 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. 10. 과정 진행 키워드: 3C Consideration Communication Cooperation 5
  11. 11. 첫째 시간기초점검 6
  12. 12. 환경설정 및 기본코드 작성   개발 환경을 확인합니다.   간단한 코드를 작성해 봅니다. 7
  13. 13. 워밍업 연습문제 0에 가까운 숫자 찾기 8
  14. 14. 전통적인 개발 진행 문제발생 요구사항 발생 기능구현 Console 에 값 찍어 보기 간단한 테스트 Yes
  15. 15.   에러발생? No
  16. 16.   완료! 9
  17. 17. 일반적인 개발1. 특정 모듈의 개발 기간이 길어질수록 개발자의 목표의식이 흐려진다. “어디까지 짰더라?” “아, 내가 지금 뭘 하는 거였지?” “이 모듈이 무슨 기능을 해야 한대더라?”2. 작업 분량이 늘어날수록 확인이 어려워진다. “로그가 어디 있더라?” “이것도 화면으로 출력해보고…” 10
  18. 18. 일반적인 개발3. 개발자의 집중력이 필요해진다. “앗! 화면 지나갔다!”4. 논리적인 오류를 찾기가 어렵다. “여기서 그러니까 이 값이 들어가면 나와야 하는 게… 아… 이게 맞던가?”5. 코드의 사용 방법과 변경 이력을 개발자의 기억력에 의존하게 되는 경우가 많다. “맞아! 개인고객 인증을 고치면 법인 고객인증 부분도 함께 고쳤어야 했었지!!”6. 테스트 케이스가 적혀 있는 엑셀 파일을 보며 매번 테스트를 실행하는 게 점점 귀찮아져서 는 점차 간소화하는 항목들이 늘어난다. “날짜? 1111. 주민번호? 우선 222222-2222222. 주소? 서울 개똥이네” 11
  19. 19. 일반적인 개발7. 코드 수정 시에 기존 코드의 정상 동작에 대한 보장이 어렵다. “휴~ 찾았다. 여길 고쳐야 하는 거였군! 아, 근데 이 금칙어 필터 모듈 혹시 다른 데서도 쓰는 거 아냐?”8. 테스트를 해보려면 소스코드에 변경을 가하는 등, 번거로운 선행 작업이 필요할 수 있다. “입고 처리를 테스트하려면, 주문이 완료됐다고 테이블에 직접 업데이트를 해줘야…”9. 그래서 소스 변경 시 해야 하는 회귀 테스트3는 곧잘 희귀 테스트(rare test)가 되기 쉽다. “아, 그걸 언제 다 다시 테스트해? 우선 급한 불부터 끄고 보자구. 집에 안 갈거야?” 12
  20. 20. 좋은 설계를 위한 노력,좋은 설계자를 만들어 내기 위한 노력 13
  21. 21. 객체 지향 기본 원칙 14
  22. 22. OCPSRPISPDemeter’s Law (=Hollywood law)IOC 15
  23. 23. 다음 두 코드 중 더 나은 디자인은?Case.1
  24. 24.   class
  25. 25.  Rental
  26. 26.  {
  27. 27.  
  28. 28.  
  29. 29.  
  30. 30.  
  31. 31.  Movie
  32. 32.  movie;
  33. 33.  
  34. 34.  
  35. 35.  
  36. 36.  
  37. 37.  Rental(Service
  38. 38.  service)
  39. 39.  {
  40. 40.  
  41. 41.  
  42. 42.  
  43. 43.  
  44. 44.  
  45. 45.  
  46. 46.  
  47. 47.  
  48. 48.  this.movie
  49. 49.  =
  50. 50.  service.getMovie();
  51. 51.  
  52. 52.  
  53. 53.  
  54. 54.  
  55. 55.  }
  56. 56.   }
  57. 57.  Case.2
  58. 58.   class
  59. 59.  Rental
  60. 60.  {
  61. 61.  
  62. 62.  
  63. 63.  
  64. 64.  
  65. 65.  Movie
  66. 66.  movie;
  67. 67.  
  68. 68.  
  69. 69.  
  70. 70.  
  71. 71.  Rental(Movie
  72. 72.  movie)
  73. 73.  {
  74. 74.  
  75. 75.  
  76. 76.  
  77. 77.  
  78. 78.  
  79. 79.  
  80. 80.  
  81. 81.  
  82. 82.  this.movie
  83. 83.  =
  84. 84.  movie;
  85. 85.  
  86. 86.  
  87. 87.  
  88. 88.  
  89. 89.  }
  90. 90.   }
  91. 91.  
  92. 92. (based on my five years of experience)Strongly recommended approach #1 테스트 주도 개발 Test-Driven Development 17
  93. 93. 기원 Origin 애자일(agile) 개발방식 중 하나인 XP의 실천방법 중 하나 18
  94. 94. TDD의 기본“프로그램을 작성하기 전에 테스트 먼저 하라!”Test the program before you write it.
  95. 95.   “잘 동작하는 깔끔한 코드” Clean code that works
  96. 96.   “질문 à 응답 à 정제 à 반복” Ask à Respond à Refine à Repeat
  97. 97.   19
  98. 98. Test Driven Development Cycle q  질문 Ask : 테스트를 작성함으로써 시스템에 질문한다. (FAIL) q  응답 Respond : 테스트를 통과하는 코드를 작성해서 질문에 대답한다. (PASS) q  정제 Refine : 아이디어를 통합하고, 불필요한 것은 제거하고, 모호한 것은 명확히 해서 대답을 정제한다. (REFACTORING) q  반복 Repeat : 다음 질문을 통해 대화를 계속 진행한다. 20
  99. 99. 코딩 시연 21
  100. 100. 몇 가지 설문 22
  101. 101. 어떤 애자일 기법을 적용하고 있습니까?관리 기법을 제외한 개발 테크닉으로만 순위를 뽑아보면 다음과 같다.1위: 단위 테스트(Unit Testing)2위: 지속적인 통합(Continuous Integration)3위: 자동화된 빌드(Automated Builds)4위: 테스트 주도 개발(TDD)5위: 짝 프로그래밍(Pair Programming)2009년 7월부터 12월까지 88개국 총 2570명을 대상으로 조사한 결과다. 23
  102. 102. 70%38% 24
  103. 103. 가장 큰 효과를 봤던 Agile 기법 CI와 일일 스탠드업 미팅, TDD가장 배우기 어려웠던 Agile 기법 개발/인수 TDD, 짝 프로그래밍 25
  104. 104. Start Test with JUnit1.  xUnit Test Frmawork 중 하나2.  Text base 혹은 GUI(Swing) base 로 구동됨3.  xUnit Style을 따른다. assert (예상값, 실제값)4.  결과는 성공:녹색/실패:붉은색 중 하나로 표시 26
  105. 105. JUnit Assertions- assertEquals( [message], expected, actual)- assertTrue( [message], expected ) / assertFalse( [message], expected )- assertNull( [message], expected ) / assertNotNull( [message], expected)- fail( [message] ) 27
  106. 106. Sample Practice q  Account Class -  계좌 잔고 조회 -  입금/출금 -  예상 복리 이자 (추가 개발) 28
  107. 107. Outlook1.  정형화된
  108. 108.  형태의
  109. 109.  테스트를
  110. 110.  작성함으로써
  111. 111.  테스트
  112. 112.  과정을
  113. 113.  자동화한다.
  114. 114.  2.  테스트
  115. 115.  결과를
  116. 116.  즉시
  117. 117.  알
  118. 118.  수
  119. 119.  있다.
  120. 120.  
  121. 121.  3.  개발하는
  122. 122.  시점
  123. 123.  이후로도
  124. 124.  지속적인
  125. 125.  테스트가
  126. 126.  보장되며
  127. 127.  4.  이를
  128. 128.  통해
  129. 129.  전체
  130. 130.  프로젝트의
  131. 131.  안정성에
  132. 132.  크게
  133. 133.  기여한다.
  134. 134.  
  135. 135.  5.  이러한
  136. 136.  모든
  137. 137.  과정이
  138. 138.  개발자에게
  139. 139.  짐이
  140. 140.  되는
  141. 141.  것이
  142. 142.  아니라
  143. 143.  즐거운
  144. 144.  커뮤니케이션의
  145. 145.   수단이
  146. 146.  된다
  147. 147.   29
  148. 148. 품질(Quality Assurance Problem) 30
  149. 149. 품질을 어떻게 높을 것인가?어느 정도 속도로 개발을 진행할 것인가? 31
  150. 150. 테스트 주도 개발을 통한품질 향상 실체화 연구 출처 : 테스트 주도 개발을 통한 품질 향상 실체화: 업계 개발팀 네 팀들에 대한 적용 결과와 경 험들 (Nachiappan Nagappan E. Michael Maximilien Thirumalesh Bhat Laurie Williams) 32
  151. 151. 단점은? 33
  152. 152. 어려운 비교결함발생 10% 증가개발기간 10% 증가선택은? 34
  153. 153. 잠깐…. 35
  154. 154. ExpertiseExperienceDivide ConquerCo-operation
  155. 155. 잘하면 고효율, 못하면 가문의 원수가 되는짝 프로그래밍Effective Pair Programming 37
  156. 156. 짝 프로그래밍(Pair Programming) 38
  157. 157. Give 효율!Take 성장감! 39
  158. 158. 결함감소율15% ~ 50% 40
  159. 159. 고려사항- 개발자(설계자)의 스킬- 업무 난이도- 작업 시간이 더 걸릴 수 있다 41
  160. 160. 혼자 할 때 보다Pair Programming 으로 할 때에업무가 더 즐거웠습니까? 출처 Factors Affecting the Perceived Effectiveness of Pair Programming in Higher Education 42
  161. 161. Comments 우리가 하루에 절반 이상을 쏟아 붓는 ‘일’이 재밌어 진다고 한다면, 효율을 떠나서 그것만큼 즐거울 일이 또 있을까요? 즐겁게 일하고 월급도 나온대요!! 43
  162. 162. 혼자 할 때 보다Pair Programming 으로 할 때에더 많이 배웠다고 생각합니까? 44
  163. 163. 45
  164. 164. 짝 프로그래밍의 성공 조건 46
  165. 165. 짝 프로그래밍은둘이 함께 같은 업무를 개발 하는 것이다? 47
  166. 166. 99% Fail!!
  167. 167. 요령과 발생할 수 있는 문제점,그리고 대처 방식을 사전에 알려주어야 함 49
  168. 168. Comments 네비게이터 네비게이터는 개발의 방향을 주도하 는 사람입니다. 속칭 ‘브레인’에 해당 하는 셈이죠. 드라이버를 움직이는 인물이기도 하죠. 때때로 내 맘 같지 않은 답답한 마음에 운전대를 뺏고 싶을 때가 종종 있을테지만, 그러면 안됩니다. 여정을 같이 하는 동료를 인내하고 신뢰해 주세요. 조금 돌아가면 어때 요? 서로를 이해하고 새로운 교훈을 받아 들일 자세가 되어 있다면 여정 은 즐거운 여행이 될 수 있습니다.드라이버 Comments드라이버는 네비게이터의 의견대로 개발을 진행해 나가는 사람입니다. 자발적인 의지로 개발을 지휘한다기 보다는 최대한네비게이터를 믿고 따라 줍니다. 물론 자신의 경험과 스킬을기반으로 끊임없이 네비게이터와 대화하고 질문하고 의도를파악해 나갑니다. 50
  169. 169. - 명시적인 역할 전환- 오래 한 역할을 하지 않을 것!- 둘 다 편안한 자세를 잡을 것!
  170. 170. 고려사항- 개발자(설계자)의 스킬- 업무 난이도- 작업 시간이 더 걸릴 수 있다
  171. 171. 효율 높았던 경우- 프로젝트 초반- 창의성이 요하거나 어려운 업무- 신입 팀원을 적응 시킬때
  172. 172. Do- 상대방에 대한 존중- 개발 업무의 목표를 잊지 않을 것
  173. 173. Don’t- 짜증- 100분 토론 Q 짜증의 표현에는 또 어떤 것들이 있을까요?
  174. 174. 실패 케이스들
  175. 175. 자존심 대결
  176. 176. 마이크로 컨트롤
  177. 177. Too easy or Too Hard
  178. 178. 성공 케이스-  오월동주(吳越同⾈舟)-  후배 키우기 혹은 업무 백업- 챙겨주기는 문화 즐겁게 일하기 = 좋은 팀웍!
  179. 179. 잘되면 짝 설계까지도 도전! Simpler, More-maintainable and catch design defects early
  180. 180. 네 번째 시간TDD 작성패턴TDD workshop by Pair Programming 62
  181. 181. TDD 작성 기본 원칙- 실패하는 테스트를 작성하기 전에는 절대로 제품 코드를 작성하지 않는다.- 실패하는 테스트 코드를 한 번에 하나 이상 만들지 않는다.- 현재 실패하고 있는 테스트를 통과하기에 충분한 정도를 넘어서는 코드는 작성하지 않는다. 63
  182. 182. 64
  183. 183. 65
  184. 184. 66
  185. 185. 67
  186. 186. 다섯 번째 시간짝 TDD실습TDD workshop by Pair Programming 68
  187. 187. 자판기 잔돈 계산- 최소 개수의 동전으로 잔돈을 돌려준다.예) 1000원 넣고 650원짜리 음료를 선택했다면, 잔돈은 100, 100, 100, 50 원으로 반환한다.-  지폐를 잔돈으로 반환하는 경우는없다고 가정한다. 69
  188. 188. 여섯 번째 시간TDD고급Advanced Technic of TDD 70
  189. 189. Mock Object 모의 객체(Mock Object) - 의존성을 분리하기 위해서 만드는 가짜 객체 71
  190. 190. Mock Object모의 객체를 사용하는 경우- 테스트 작성을 위한 환경 구축이 어려워서- 테스트가 특정 경우나 순간에 의존적이라- 테스트 시간이 오래 걸려서 72
  191. 191. Mock Object테스트 더블(Test Double)- dummy- stub- fake- spy- Mock 73
  192. 192. 테스트 더블 - Dummy겨우 컴파일만 되는 바보 객체 74
  193. 193. 테스트 더블 - Stub특정 상태를 대표해서 동작하는 객체 75
  194. 194. 테스트 더블 - Fake일부 기능성 로직이 들어가 있는 객체 76
  195. 195. 테스트 더블 - Spy객체의 내부 상태를 기록해 주는 객체 77
  196. 196. 테스트 더블 - Mock객체의 내부 상태뿐 아니라 동작까지도감시할 수 있게 만든 객체 78
  197. 197. 실습모의 객체를 이용한 테스트 작성 79
  198. 198. MockitoCreateMock 인터페이스에 해당하는 Mock 객체를 만든다.Stub 테스트에 필요한 Mock 객체의 동작을 지정한다 (단, 필요 시에만).Exercise 테스트 메소드 내에서 Mock 객체를 사용한다.Verify 메소드가 예상대로 호출됐는지 검증한다. 80
  199. 199. Mockito행위 기반 테스트 81
  200. 200. MockitoStub 테스트 82
  201. 201. QA 83
  202. 202. 실습 – 모바일 교통카드-  장비 : 핸드폰, 단말기-  GPS 및 JVM 탑재되어 있음-  네트워크 통신은 고려하지 않음 84
  203. 203. 요금체계 – 모바일 교통카드 기본 요금 대상 요금 일반 900원 청소년 720원 초등학생 450원 85
  204. 204. 추가요금 - 모바일 교통카드버스 기본요금 이외의 추가요금 없음지하철 10km초과 ~40km까지 : 5km 마다 100원 40km초과시 : 10km 마다 100원 * 단, 환승은 고려하지 않는다. 86
  205. 205. 거리계산 – 모바일 교통카드 서울시청 (4, 5) 거리 = SQRT(3*3 + 4*4) = 5 km 여의도역 (1, 1) 87
  206. 206. 개발목표   No1. 최대한 빠른 시간 내에   No2. 가급적 정확히   No3. 확장을 고려? 88

×