More Related Content
What's hot
What's hot (20)
Similar to KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"
Similar to KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가" (20)
KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"
- 2. co-duck.com
- 3. co-duck.com
- 4. 배달의민족 사용법 목록 진입 가게 진입 주문 결제
- 5. 프론트 시스템 개편 주문 시스템 개편 결제 시스템 개편
- 7. •테스트로 얻을 수 있는 것 •무엇을 테스트할 것인가? •어떻게 테스트할 것인가? •Tip & Rule
- 8. 테스트로부터 얻을 수 있는 것
- 9. 안정감과 자신감
- 10. •현재와 미래의 나 •현재와 미래의 동료 대상은?
- 11. 무엇을 테스트할 것인가?
- 12. “로또를 구현하라!”
- 13. 요청 6개 숫자 생성
- 14. •6개의 숫자를 반환 •중복되지 않은 숫자 •랜덤하게 반환 요구사항을 정리해보면..
- 15. 1. 구현 vs 설계
- 17. 1. 빈 Set을 만들고
- 18. 2. 전체 숫자들을 생성하고
- 19. 3. 숫자를 Collections.shuffle 로 섞어준다.
- 20. 4. 6개의 숫자가 될 때까지 add()
- 22. •6개의 숫자를 반환 •중복되지 않은 숫자 •랜덤하게 반환
- 23. •6개의 숫자를 반환 •중복되지 않은 숫자 •랜덤하게 반환
- 24. “중복에 대해서도 테스트되어야 하지 않을까요?”
- 25. “중복에 대해서도 테스트되어야 하지 않을까요?” “저는 Set 으로 구현해서 중복이 나올 수가 없어요.”
- 26. “중복에 대해서도 테스트되어야 하지 않을까요?” “저는 Set 으로 구현해서 중복이 나올 수가 없어요.”
- 27. 구현은 언젠가 어떻게든 변할 수 있다
- 28. 장애배포
- 29. 편안배포
- 30. public A actA() void actATest() 구현 테스트
- 31. public A actA() void actATest() public B actB() void actBTest() 구현 테스트
- 32. public A actA() void actATest() public B actB() void actBTest() public C actC() void actCTest() 구현 테스트
- 33. public A actA() void actATest() public B actB() void actBTest() public C actC() void actCTest() private D actD() ! 구현 테스트
- 34. public A actA() void actATest() public B actB() void actBTest() public C actC() void actCTest() private D actD() ! 구현 테스트 여기서 공감했다면 구현 테스트를 하고 있을 가능성이 매우 큼
- 35. public A actA() void actATest() public B actB() void actBTest() public C actC() void actCTest() void actC2Test()
- 36. 구현을
- 37. 구현을 테스트
- 38. 구현을 테스트
- 39. 설계를
- 40. 설계를 테스트
- 41. 설계를 테스트
- 42. “설계를 테스트”
- 43. 2. 테스트 가능한 것, 불가능한 것
- 44. “[OKKY 세미나] 정진욱 - 테스트하기 쉬운 코드로 개발하기” 중
- 45. Non-Testable • Random, Shuffle, LocalDate.now() • 외부 세계 • HTTP • 외부 저장소 “제어할 수 없는 영역”
- 46. 테스트 외부 API
- 48. 테스트 외부 API FAIL!
- 49. 테스트 외부 API FAIL! “제어할 수 없는 영역은 멱등한 결과를 보장할 수 없다”
- 50. •6개의 숫자를 반환 •중복되지 않은 숫자 •랜덤하게 반환
- 51. •6개의 숫자를 반환 •중복되지 않은 숫자 •랜덤하게 반환테스트 불가능한 것
- 53. •6개의 숫자를 반환 •중복되지 않은 숫자 •랜덤하게 반환 의도한 전략대로 반환
- 55. “항상 성공할 수 있는 것, 항상 동일한 결과가 나올 수 있는 것을 테스트”
- 56. 어떻게 테스트할 것인가?
- 57. 1. 테스트 가능한 것, 불가능한 것
- 58. “[OKKY 세미나] 정진욱 - 테스트하기 쉬운 코드로 개발하기” 중
- 59. “[OKKY 세미나] 정진욱 - 테스트하기 쉬운 코드로 개발하기” 중
- 60. 거리 배달팁 배달팁 할인 배달팁 계산
- 61. 배달팁 계산 거리 배달팁 배달팁 할인
- 62. calculateDeliveryTip calculateDeliveryTip caculateDiscount배달팁 계산 배달팁 할인 계산 deliveryTipController isValid calculateNow calculateNow isValid 배달팁 계산
- 64. Non-Testable • Random, Shuffle, LocalDate.now() • 외부 세계 • HTTP • 외부 저장소 “제어할 수 없는 영역”
- 65. calculateDeliveryTip calculateDeliveryTip caculateDiscount배달팁 계산 배달팁 할인 계산 deliveryTipController isValid calculateNow calculateNow isValidNon-Testable 배달팁 계산
- 67. “[OKKY 세미나] 정진욱 - 테스트하기 쉬운 코드로 개발하기” 중 ?
- 72. •현재 시간에 해당하는 배달팁과 할인 금액 합산 특정 시간에 해당하는 배달팁과 할인 금액 합산
- 76. 배달팁 계산 calculateDeliveryTip(LocalDateTime) calculateDeliveryTip(LocalDateTime) caculateDiscount(LocalDateTime) deliveryTipController isValid(LocalDateTime) calculateAt(LocalDateTime) calculateAt(LocalDateTime) Non-Testable isValid(LocalDateTime) 한 모듈로서의 의미를 지니는 가장 바깥 쪽
- 77. “테스트 불가능한 영역을 Boundary Layer 로 올려서 테스트 가능하도록 변경”
- 78. 2. Java, Spring Framework
- 79. 위에서 했었던..
- 80. “로또를 웹으로 구현하라!”
- 83. @SpringBootTest Test 는 Boot 로!
- 84. @SpringBootTest
- 85. Spring Context 가 필요할까?
- 86. Spring Context 가 필요없다.
- 87. Spring Context 가 필요할까?
- 88. Spring Context 가 필요없다.
- 89. Spring Context 는 느리다 빠른 피드백을 받을 수 없다.
- 90. Spring Framework에서 이 필드의 의미는?
- 91. Spring Framework에 이 필드의 의미는? 필수 의존성
- 92. Java 에서 이 필드의 의미는?
- 93. Java 에서 이 필드의 의미는? Nullable
- 95. Spring Context 의 오용은 언어의 본질을 망각하게 할 수 있다.
- 97. “Context, Framework 종속적이지 않은 테스트를 우선”
- 98. 3. Test Double
- 99. 테스트 할 수 없는 영역에 대한 외부 요인을 부여할 수 있도록 도와줌
- 102. “무엇을 Test Double 로 처리해야할까”
- 103. 1 2 3 4 테스트 하고 싶은 영역
- 104. TestDouble TestDouble TestDouble 1 2 3 4 Test Double 을 사용하는 것은 테스트가 구현을 알아야 한다는 것
- 105. TestDouble TestDouble TestDouble 1 2 3 4
- 106. TestDouble TestDouble TestDouble 1 2 3 4 반환 타입 변경
- 107. TestDouble TestDouble TestDouble 1 2 3 4 입력 값 변경
- 108. TestDouble TestDouble TestDouble 1 2 3 4 Test Double 의 남용은 구현 테스트로 유도할 수도 있다.
- 109. 1 2 3 4 Boundary Context 까지 끌어올려진 Non-Testable
- 110. 1 2 3 4 TestDouble
- 111. “편리하지만 사용을 의식하여 최소화”
- 112. 순수 자바 어플리케이션으로는 테스트할 수 없는 것
- 113. • 저장소 입출력 검증 • SPEC 검증 • 내부 Controller • 외부 API
- 114. 4. Embedded
- 115. Spring Data JPA High Level Client Row Level Client Spring Cloud
- 116. “Embedded 활용 가능” RDB h2database/h2 Redis kstyrc/embedded-redis Mongo flapdoodle-oss/de.flapdoodle.embed.mongo Dynamo amazonaws/DynamoDBLocal MQ softwaremill/elasticmq SQS jojoldu/spring-boot-aws-mock
- 117. System 제어할 수 없는 영역을
- 118. System 제어 가능하도록 만들 수 있다
- 119. 테스트 시작 테스트 종료 Embedded 시스템 시작 Embedded 시스템 종료 테스트와 Embedded 시스템은 동일한 라이프사이클을 갖도록 구성
- 120. 테스트와 Embedded 시스템은 동일한 라이프사이클을 갖도록 구성
- 121. Local Embedded테스트 정확도 > Local Embedded테스트 피드백 속도 < Local Embedded테스트 안정성 <
- 122. 5. EndPoint Test
- 124. @Controller @Service @Repository 요청 스팩 검증 응답 스팩 검증
- 125. @Controller @MockBean 요청 스팩 검증 응답 스팩 검증 테스트의 목적은 요청과 응답 스팩 검증만으로 제한하는게 정신 건강에 좋을 것이라고 생각
- 126. • MockMvc With RestDocs • REST Assured With RestDocs • WebTestClient With RestDocs 테스트와 문서를 한방에! https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-testing.html#boot-features-testing-spring-boot-applications-testing-autoconfigured-rest-docs
- 128. 6. Spring Cloud Contract
- 131. [Producer] Generate Contract Test
- 132. [Producer] Test
- 133. [Producer] Test
- 134. [Consumer] Test
- 135. TIP & RULE
- 136. 1. 테스트는 상호 독립적으로 작성
- 137. TEST1: 데이터 삽입 TEST2 : 데이터 수정
- 138. TEST1: 데이터 삽입 TEST2 : 데이터 수정 TEST3 : 데이터 삭제
- 139. TEST1: 데이터 삽입 TEST2 : 데이터 수정 TEST3 : 데이터 삭제
- 140. 모든 테스트의 순서와 관계를 생각하며 테스트를 작성하기 어려움
- 141. 공유되는 자원은 초기화하여 다른 테스트에 영향을 받지 않도록 TEST1 TEST2 @After void tearDown { allDataSource.clear() }
- 142. 테스트 간 서로 영향을 미치지 않도록 테스트는 상호 독립적으로 작성
- 143. 단계가 필요하다면 JUnit 5의 DynamicTest 추천
- 144. 2. 테스트 안에 의도와 목 이 드러나도록 작성
- 145. @Test { } 어떠한 조건에서 무엇을 수행했을 때 어떤 결과가
- 146. @Test { } 무엇을 수행했을 때 어떤 결과가 어떠한 조건에서 Import.sql @Before TestConfiguration @Test
- 147. @Test { } 어떤 결과가 어떠한 조건에서 무엇을 수행했을 때 Import.sql @Before TestConfiguration @Test
- 148. @Test { } 어떠한 조건에서 무엇을 수행했을 때 어떤 결과가 테스트 코드 역시 가독이 중요
- 149. 3. 테스트 코드도 리펙토링 대상
- 153. @Test CODE CODE CODE @Test CODE CODE @Test @Test @Test 시간이 흐름에 따라 코드는 늘어갈 것
- 154. @Test CODE CODE CODE @Test CODE CODE @Test @Test @Test 시간이 흐름에 따라 코드 와 테스트는 늘어갈 것
- 157. @Test CODE CODE CODE @Test @Test @Test 코드양에 대한 이야기가 아닌 가독, 안정성, 요구사항 정리 등 비지니스 코드와 동일한 수준의 리팩토링이 함께 이루어져야 한다
- 158. 정리
- 159. 무엇을 테스트할 것인가? 1. 설계를 테스트 2. 테스트 가능한 것을 테스트 어떻게 테스트할 것인가? 1. 테스트 불가능한 영역을 Boundary Layer 까지 올려서 테스트 가능하도록 변경 2. Context, Framework 종속적이지 않도록 테스트 3. Test Double 사용 4. Embedded System 사용 5. EndPoint Test 도구 사용하여 내부 API Spec 테스트 6. Spring Cloud Contract 로 외부 API Spec 테스트 TIP & RULE 1. 테스트는 상호 독립적으로 작성 2. 테스트 안에서 의도와 목적이 모두 드러나도록 작성 3. 테스트 코드도 리펙토링
- 160. 그러나 가장 중요한 것은 안정감과 자신감 기준을 최대한 지키되 기준을 지키기 위해 안정감과 자신감을 포기할 필요는 없다.