KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"

무엇을
어떻게
테스트할 것인가?

배달의민족 사용법
목록 진입 가게 진입 주문 결제

프론트 시스템 개편 주문 시스템 개편 결제 시스템 개편

•테스트로 얻을 수 있는 것
•무엇을 테스트할 것인가?
•어떻게 테스트할 것인가?
•Tip & Rule

테스트로부터
얻을 수 있는 것

•현재와 미래의 나
•현재와 미래의 동료
대상은?

무엇을 테스트할 것인가?

•6개의 숫자를 반환
•중복되지 않은 숫자
•랜덤하게 반환
요구사항을 정리해보면..

2. 전체 숫자들을 생성하고

3. 숫자를 Collections.shuffle 로 섞어준다.

4. 6개의 숫자가 될 때까지 add()

•랜덤하게 반환

“중복에 대해서도 테스트되어야 하지 않을까요?”

“중복에 대해서도 테스트되어야 하지 않을까요?”
“저는 Set 으로 구현해서 중복이 나올 수가 없어요.”

구현은 언젠가 어떻게든 변할 수 있다

public A actA() void actATest()
구현 테스트

public B actB() void actBTest()
구현 테스트

public C actC() void actCTest()
구현 테스트

private D actD()
!
구현 테스트

private D actD()
!
구현 테스트
여기서 공감했다면
구현 테스트를 하고 있을 가능성이 매우 큼

void actC2Test()

2. 테스트 가능한 것, 불가능한 것

“[OKKY 세미나] 정진욱 - 테스트하기 쉬운 코드로 개발하기” 중

Non-Testable
• Random, Shuﬄe, LocalDate.now()

• 외부 세계

• HTTP

• 외부 저장소
“제어할 수 없는 영역”

테스트
외부 API
값 변경
배포
장애

테스트
외부 API
FAIL!
“제어할 수 없는 영역은 멱등한 결과를 보장할 수 없다”

•랜덤하게 반환테스트 불가능한 것

•랜덤하게 반환 의도한 전략대로 반환

“항상 성공할 수 있는 것,
항상 동일한 결과가 나올 수 있는 것을
테스트”

어떻게 테스트할 것인가?

1. 테스트 가능한 것, 불가능한 것

거리
배달팁 배달팁 할인
배달팁 계산

배달팁 계산
거리
배달팁 배달팁 할인

calculateDeliveryTip
calculateDeliveryTip caculateDiscount배달팁 계산 배달팁 할인 계산
deliveryTipController
isValid
calculateNow calculateNow
isValid
배달팁 계산

calculateDeliveryTip caculateDiscount배달팁 계산 배달팁 할인 계산
isValid
isValidNon-Testable
배달팁 계산

calculateDeliveryTip caculateDiscount
isValid
isValid
Non-Testable
배달팁 계산

“[OKKY 세미나] 정진욱 - 테스트하기 쉬운 코드로 개발하기” 중
?

isValid(LocalDateTime)
Non-Testable
배달팁 계산

calculateNow(LocalDateTime) calculateNow(LocalDateTime)
Non-Testable
배달팁 계산

•현재 시간에 해당하는 배달팁과 할인 금액 합산
특정 시간에 해당하는 배달팁과 할인 금액 합산

calculateAt(LocalDateTime) calculateAt(LocalDateTime)
Non-Testable
배달팁 계산

calculateDeliveryTip(LocalDateTime) caculateDiscount(LocalDateTime)
Non-Testable
배달팁 계산

calculateDeliveryTip(LocalDateTime)
Non-Testable
배달팁 계산

배달팁 계산
calculateDeliveryTip(LocalDateTime)
Non-Testable
한 모듈로서의 의미를 지니는 가장 바깥 쪽

“테스트 불가능한 영역을  
Boundary Layer 로 올려서  
테스트 가능하도록 변경”

“로또를 웹으로 구현하라!”

@Bean
@Service
@Compoent
Spring Framework! Bean으로 만들어야겠지?

@SpringBootTest
Test 는 Boot 로!

Spring Context 가 필요할까?

Spring Context 가 필요없다.

Spring Context 는 느리다
빠른 피드백을 받을 수 없다.

Spring Framework에서 이 필드의 의미는?

Spring Framework에 이 필드의 의미는?
필수 의존성

Java 에서 이 필드의 의미는?

Java 에서 이 필드의 의미는?
Nullable

Spring Context 의 오용은
언어의 본질을 망각하게 할 수 있다.

“Context, Framework 종속적이지  
않은 테스트를 우선”

테스트 할 수 없는 영역에 대한 외부 요인을 부여할 수 있도록 도와줌

“무엇을 Test Double 로 처리해야할까”

1 2 3 4
테스트 하고 싶은 영역

TestDouble TestDouble TestDouble
1 2 3 4
Test Double 을 사용하는 것은
테스트가 구현을 알아야 한다는 것

1 2 3 4

1 2 3 4
반환 타입 변경

1 2 3 4
입력 값 변경

1 2 3 4
Test Double 의 남용은 구현 테스트로 유도할 수도 있다.

1 2 3 4
Boundary Context 까지
끌어올려진 Non-Testable

“편리하지만 사용을 의식하여 최소화”

순수 자바 어플리케이션으로는  
테스트할 수 없는 것

• 저장소 입출력 검증

• SPEC 검증

• 내부 Controller

• 외부 API

Spring Data
JPA
High Level Client
Row Level Client
Spring Cloud

“Embedded 활용 가능”
RDB h2database/h2
Redis kstyrc/embedded-redis
Mongo ﬂapdoodle-oss/de.ﬂapdoodle.embed.mongo
Dynamo amazonaws/DynamoDBLocal
MQ softwaremill/elasticmq
SQS jojoldu/spring-boot-aws-mock

System
제어할 수 없는 영역을

System
제어 가능하도록 만들 수 있다

테스트 시작
테스트 종료
Embedded  
시스템
시작
Embedded  
시스템
종료
테스트와 Embedded 시스템은 동일한 라이프사이클을 갖도록 구성

테스트와 Embedded 시스템은 동일한 라이프사이클을 갖도록 구성

Local Embedded테스트 정확도 >
Local Embedded테스트 피드백 속도 <
Local Embedded테스트 안정성 <

•MockMvc
•REST Assured
•WebTestClient
Spring Framework Support

@Controller
@Service
@Repository
요청 스팩 검증 응답 스팩 검증

@Controller
@MockBean
요청 스팩 검증 응답 스팩 검증
테스트의 목적은 요청과 응답 스팩 검증만으로 제한하는게 정신 건강에 좋을 것이라고 생각

• 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-autoconﬁgured-rest-docs

http://woowabros.github.io/experience/2018/12/28/spring-rest-docs.html
Spring REST Docs

[Producer] Generate Contract Test

1. 테스트는 상호 독립적으로 작성

TEST1: 데이터 삽입
TEST2 : 데이터 수정

TEST1: 데이터 삽입
TEST2 : 데이터 수정
TEST3 : 데이터 삭제

모든 테스트의 순서와 관계를 생각하며 테스트를 작성하기 어려움

공유되는 자원은 초기화하여 다른 테스트에 영향을 받지 않도록
TEST1
TEST2
@After
void tearDown {
allDataSource.clear()
}

테스트 간 서로 영향을 미치지 않도록
테스트는 상호 독립적으로 작성

단계가 필요하다면 JUnit 5의 DynamicTest 추천

2. 테스트 안에 의도와 목 이  
드러나도록 작성

@Test
{
}
어떠한 조건에서
무엇을 수행했을 때
어떤 결과가

@Test
{
}
어떤 결과가
Import.sql
@Before
TestConfiguration
@Test

@Test
{
}
어떤 결과가
테스트 코드 역시 가독이 중요

3. 테스트 코드도 리펙토링 대상

@Test
CODE
CODE
CODE @Test
CODE @Test

@Test
CODE
CODE
CODE @Test
CODE @Test
@Test

@Test
CODE
CODE
CODE @Test
CODE
CODE
@Test
@Test
@Test
시간이 흐름에 따라 코드는 늘어갈 것

@Test
CODE
CODE
CODE @Test
CODE
CODE
@Test
@Test
@Test
시간이 흐름에 따라 코드 와 테스트는 늘어갈 것

@Test
CODE
CODE
CODE @Test
@Test
@Test
@Test
리펙토링!

@Test
CODE
CODE
CODE @Test
@Test
@Test
리펙토링!

@Test
CODE
CODE
CODE @Test
@Test
@Test
코드양에 대한 이야기가 아닌 가독, 안정성, 요구사항 정리 등
비지니스 코드와 동일한 수준의 리팩토링이 함께 이루어져야 한다

무엇을 테스트할 것인가? 
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. 테스트 코드도 리펙토링

그러나 가장 중요한 것은 안정감과 자신감
기준을 최대한 지키되 기준을 지키기 위해
안정감과 자신감을 포기할 필요는 없다.

KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"

Similar to KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가" (20)

More from 용근 권

More from 용근 권 (6)

KSUG 스프링캠프 2019 발표자료 - "무엇을 테스트할 것인가, 어떻게 테스트할 것인가"