89
행행행 행행행 행행 행행행 행행행 BaaS 행행행 I 임임임

행복한 개발을 위한_테스트_케이스

Embed Size (px)

DESCRIPTION

버그 발생은 어쩔 수 없다. 그런데 그 인지가 늦어지면 삽질스러워진다. 이를 방지하기 위한 유일한 방법은 오직 테스트 케이스 뿐이다.

Citation preview

Page 1: 행복한 개발을 위한_테스트_케이스

행복한 개발을 위한테스트 케이스BaaS 기술팀 I 임도형

Page 2: 행복한 개발을 위한_테스트_케이스

삽질이 싫어요

임도형

개발 문화 , 삽질 증오

Page 3: 행복한 개발을 위한_테스트_케이스

삽질이 싫어요

Page 4: 행복한 개발을 위한_테스트_케이스

삽질이 싫어요

개발 경력 15 년 쯤 .

개발로 먹고 살고 싶고 .

그것도 행복하게 .

Page 5: 행복한 개발을 위한_테스트_케이스

행복한 개발을 하고 싶다 .

쫌 가치 있는

생산성 있게

머리 쓰는 똘똘한

삽질이 싫어요

Page 6: 행복한 개발을 위한_테스트_케이스

그런데

삽질이 날…

삽질이 싫어요

Page 7: 행복한 개발을 위한_테스트_케이스

버그 때문 ?

삽질이 싫어요

버그 잡이가 삽질 ?

Page 8: 행복한 개발을 위한_테스트_케이스

버그는 당연 .

삽질이 싫어요

버그잡이는 개발의 일부 .

버그잡이가 삽질은 아닙니다 .

Page 9: 행복한 개발을 위한_테스트_케이스

하지만 ,

삽질스런 버그잡이는

피하고 싶다 .

삽질이 싫어요

Page 10: 행복한 개발을 위한_테스트_케이스

버그 발생 ( 숨어있는 )

삽질이 싫어요

코드 수정 / 추가

&

Page 11: 행복한 개발을 위한_테스트_케이스

버그

삽질이 싫어요

기존 코드에서

추가 코드에서

Page 12: 행복한 개발을 위한_테스트_케이스

삽질이 싫어요

그리고 버그 인지

Page 13: 행복한 개발을 위한_테스트_케이스

간격이 멀수록

삽질스러워 진다 .

삽질이 싫어요

발생과 인지

Page 14: 행복한 개발을 위한_테스트_케이스

빠른 버그 인지 !

삽질이 싫어요

행복한 개발의 핵심 .

Page 15: 행복한 개발을 위한_테스트_케이스

영향도 분석 ?

삽질이 싫어요

불가능하다 .

Page 16: 행복한 개발을 위한_테스트_케이스

영향도 분석 ?

삽질이 싫어요

어려운 것이 아니라

불가능하다 .

Page 17: 행복한 개발을 위한_테스트_케이스

유일한 방법은

삽질이 싫어요

오직

테스트 케이스

Page 18: 행복한 개발을 위한_테스트_케이스

테스트 케이스의 목적

삽질이 싫어요

새로운 버그의 발생을

즉시 파악 .

Page 19: 행복한 개발을 위한_테스트_케이스

테스트 케이스

Page 20: 행복한 개발을 위한_테스트_케이스

테스트 코드 ?

테스트 케이스

작업 후 동작 확인 위한 코드

Page 21: 행복한 개발을 위한_테스트_케이스

테스트 코드 ?

테스트 케이스

보통은 System.out.println()

혹은 직접 손과 눈으로

Page 22: 행복한 개발을 위한_테스트_케이스

테스트 코드는

테스트 케이스가 아니다 .

테스트 케이스

버그의 발생을 파악할 수 없다 .

Page 23: 행복한 개발을 위한_테스트_케이스

JUnit 쓰면 테스트 케이스 ?

테스트 케이스

그럼 뭐가 테스트 케이스 ?

Page 24: 행복한 개발을 위한_테스트_케이스

을 파악할 수 있어야

테스트 케이스

테스트 케이스

버그 발생

Page 25: 행복한 개발을 위한_테스트_케이스

언제나 정상동작을

확인할 수 있어야

테스트 케이스

내일도 모레도 1 년뒤에도

Page 26: 행복한 개발을 위한_테스트_케이스

재사용 가능해야

테스트 케이스

테스트 케이스

Page 27: 행복한 개발을 위한_테스트_케이스

손으로 해야 한다면

테스트 케이스

시간

확인 안한다 .

, 복잡, 게으름, 몰라서

Page 28: 행복한 개발을 위한_테스트_케이스

자동화 가능해야

테스트 케이스

테스트 케이스

Page 29: 행복한 개발을 위한_테스트_케이스

테스트 케이스라 칠라믄

테스트 케이스

재사용 가능해야

자동화 가능해야

Page 30: 행복한 개발을 위한_테스트_케이스

테스트 케이스

테스트 케이스

수정된 / 추가된 코드로 인하여

기존 코드에 버그가 발생하지 않았음을

보장할 수 있는 효율적인 유일한 방법 .

Page 31: 행복한 개발을 위한_테스트_케이스

시스템 테스트 , 혹은 QA

테스트 케이스

효율적이지 않다 .

최소한의 대응이다 .

Page 32: 행복한 개발을 위한_테스트_케이스

개발자 스스로가

지금 , 전부

실행시킬 수 있어야 한다 .

테스트 케이스

Page 33: 행복한 개발을 위한_테스트_케이스

테스트 케이스 작성은

추가적인 작업이 아니다 .

테스트 케이스

Page 34: 행복한 개발을 위한_테스트_케이스

뭔가 수정되었다면

테스트 케이스

확인은 당연

수정된 것의 동작

기존의 것의 동작

Page 35: 행복한 개발을 위한_테스트_케이스

추가되는 테스트 케이스

테스트 케이스

추가된 코드 동작 확인

추후 기존 코드 동작 확인

Page 36: 행복한 개발을 위한_테스트_케이스

테스트 케이스는

테스트 케이스

가능해야

자동화

재사용

가능해야

Page 37: 행복한 개발을 위한_테스트_케이스

목숨 걸고 지켜야

Page 38: 행복한 개발을 위한_테스트_케이스

방치된 실패 1 개

목숨 걸고 지켜야

전체 실패와 같다 .

Page 39: 행복한 개발을 위한_테스트_케이스

실패 1 개가 있었으면

목숨 걸고 지켜야

테스트 케이스를 아예 안 돌린다 .

작업한 코드를 검증하지 않는다 .

신규 버그를 알지 못한다 .

심지어 버그를 알고도 커밋한다 .

Page 40: 행복한 개발을 위한_테스트_케이스

100

목숨 걸고 지켜야

from http://www.creativereview.co.uk/cr-blog/2012/july/alex-chinneck-smashed-windows

- 1= 0

Page 41: 행복한 개발을 위한_테스트_케이스

커밋의 조건

목숨 걸고 지켜야

컴파일 성공

테스트 전부 성공

컴파일 경고 없고

커버리지 만족

?

?

Page 42: 행복한 개발을 위한_테스트_케이스

컴파일 경고와

커버리지도

마찬가지

목숨 걸고 지켜야

Page 43: 행복한 개발을 위한_테스트_케이스

행복하지 않은 현실

Page 44: 행복한 개발을 위한_테스트_케이스

테스트 케이스 없 ~ 다

행복하지 않은 현실

실패하는 테스트 케이스

깨지기 쉬운 테스트 케이스

가짜 테스트 케이스

Page 45: 행복한 개발을 위한_테스트_케이스

행복하지 않은 현실

“ 일정이 너무 빡빡해서…”

“ 본 코드 짤 시간도…”

테스트 케이스 없 ~ 다

Page 46: 행복한 개발을 위한_테스트_케이스

행복하지 않은 현실

“ 테스트 코드 있잖아…”

“ 눈으로 확인했는데…”

가짜 테스트 케이스

Page 47: 행복한 개발을 위한_테스트_케이스

행복하지 않은 현실

“ 안 깨지게 하려면 ,

손이 너무 많이 가…”

깨지기 쉬운 테스트 케이스

Page 48: 행복한 개발을 위한_테스트_케이스

행복하지 않은 현실

“ 나만 열심히 해 봤자…”

“ 어차피 뒤집힐텐데…”

“ 자동화 하기 어려워…”

Page 49: 행복한 개발을 위한_테스트_케이스

테스트 케이스는

삽질 방지하자는 것

행복하지 않은 현실

Page 50: 행복한 개발을 위한_테스트_케이스

행복하려면

Page 51: 행복한 개발을 위한_테스트_케이스

개발자가

열심히 작성하면 된다 ?

행복하려면

Page 52: 행복한 개발을 위한_테스트_케이스

프로젝트 차원으로 지원해야

행복하려면

일정

테스트 용이한 아키텍처

편의성 있는 프레임웤

개발자 지원

Page 53: 행복한 개발을 위한_테스트_케이스

프로젝트 차원 ?

행복하려면

개발자 개인의 책임이 아닌

관리자 , 경영자의 의지

Page 54: 행복한 개발을 위한_테스트_케이스

관리자 , 경영자를

깨우치게 해야

행복하려면 - 일정

Page 55: 행복한 개발을 위한_테스트_케이스

상상해 봅시다 .

행복하려면 - 일정

외국 어느 SW 회사에 입사 .

빵빵한 테스트 케이스 .

다운받아 작업 전에 실행해보니 전체 성공 .

테스트 케이스로 타 모듈 사용 방법 파악 .

기능 추가 후 새 테스트 케이스 추가 .

전체 실행하니 , 저쪽에서 실패 .

직관적으로 원인 깨닫고 보완 .

Page 56: 행복한 개발을 위한_테스트_케이스

현실은

행복하려면 - 일정

국내 어느 SW 회사에 입사 .

테스트 케이스 전무 .

다운받아 작업 전에… 실행해 볼것 없고 .

빈약한 문서에 코드 보며 타 모듈 파악에 헉헉 .

기능 추가 후 동작확인을 눈으로 확인 .

3 달 후 버그 리포팅 .

재현 , 분석 , 삽질로 처리 .

Page 57: 행복한 개발을 위한_테스트_케이스

비용 ?

행복하려면 - 일정

상상 : 테스트 케이스 작성 비용

+ 순간적 버그 픽스 비용

(~=0)

현실 : 0

+ 추후 버그 픽스 비용

+ more, more

Page 58: 행복한 개발을 위한_테스트_케이스

일정은 어떻게든

극복될 것 같습니다 .

비용이란 측면에서

행복하려면 - 일정

Page 59: 행복한 개발을 위한_테스트_케이스

한 곳 수정하면

온갖 곳 다 신경 써야 하는 .

행복하려면 - 아키텍처

하나 작성하려면

온갖 모듈 다 로딩해야 하는 .

Page 60: 행복한 개발을 위한_테스트_케이스

아키텍처의 문제

행복하려면 - 아키텍처

모듈 간에 너무 끈끈

테스트 편의성 고려하지 않은

Page 61: 행복한 개발을 위한_테스트_케이스

각 모듈 간의 의존성 제거

행복하려면 - 아키텍처

Dependency Injection

Page 62: 행복한 개발을 위한_테스트_케이스

시스템 아키텍처

행복하려면 - 아키텍처

서브 프로젝트 간 관계

패키징 방법

테스트 용이하도록

Page 63: 행복한 개발을 위한_테스트_케이스

깨지기 쉬운 테스트 케이스 ?

행복하려면 - 프레임웤

기반 전제에 기인

개발자 개인이 극복 어렵다 .

Page 64: 행복한 개발을 위한_테스트_케이스

프레임웤으로 지원해야

행복하려면 - 프레임웤

테스트 케이스 개발이 편해야

JUnit 만으론 부족

Page 65: 행복한 개발을 위한_테스트_케이스

테스트를 위한 프레임웤도

개발 범위에 포함되어야 한다 .

행복하려면 - 프레임웤

Page 66: 행복한 개발을 위한_테스트_케이스

행복하려면 – 개발자 지원

개발자 지원 ?

Page 67: 행복한 개발을 위한_테스트_케이스

#H3 에서 느끼게 하자 .

행복하려면 – 개발자 지원

기술적인 것이 아니다 .

믿음과 경험 , 감동 , 습관 .

Page 68: 행복한 개발을 위한_테스트_케이스

프로젝트 차원에서

지원하자 .

행복하려면

Page 69: 행복한 개발을 위한_테스트_케이스

그보다 중요한 것은

개발자의 의지

행복하려면

Page 70: 행복한 개발을 위한_테스트_케이스

유용할 수 있는

Page 71: 행복한 개발을 위한_테스트_케이스

테스트 케이스가 튼튼하려면

유용할 수 있는

기반 데이터를 전제 X

실행 순서를 전제 X

리소스를 공유 X

DB 설정파일

Page 72: 행복한 개발을 위한_테스트_케이스

Mock 서브시스템 (DBMS)

유용할 수 있는

테스트 시 디비를 구축 .

디비 스키마도 버전 관리 .

Page 73: 행복한 개발을 위한_테스트_케이스

Mock 서브시스템 (Cassandra)

유용할 수 있는

테스트 시 Cassandra 를 구동 .

Page 74: 행복한 개발을 위한_테스트_케이스

각 테스트 케이스별 리소스

유용할 수 있는

Page 75: 행복한 개발을 위한_테스트_케이스

설정 오버라이딩

유용할 수 있는

테스트만을 위한 사항만 설정

테스트 케이스의 설정

시스템 기본 설정

custom xml, properties 도 오버라이딩 .

Page 76: 행복한 개발을 위한_테스트_케이스

테스트 지원 프레임웤 ?

유용할 수 있는

구동 시 Mock 서브시스템 구동

오버라이딩한 설정 로딩

리소스 default 로딩

Page 77: 행복한 개발을 위한_테스트_케이스

메소드 이름을 한글로

유용할 수 있는

Page 78: 행복한 개발을 위한_테스트_케이스

요구사항 이름의 테스트 케이스

유용할 수 있는

Page 79: 행복한 개발을 위한_테스트_케이스

Jetty 를 사용한 시스템 테스트

유용할 수 있는

패키징 없이 테스트

embeddable WAS

Page 80: 행복한 개발을 위한_테스트_케이스

시스템 테스트도

통합테스트도

자동화해야 한다 .

유용할 수 있는

Page 81: 행복한 개발을 위한_테스트_케이스

깨진 테스트 케이스 ,

차라리 삭제 .

유용할 수 있는

Page 82: 행복한 개발을 위한_테스트_케이스

깨지기 쉬운 테스트 케이스 ,

커밋 전

리뷰를 통해 보완 .

유용할 수 있는

Page 83: 행복한 개발을 위한_테스트_케이스

정리

Page 84: 행복한 개발을 위한_테스트_케이스

행복하기 위한 필수

재사용 , 자동화되어야

프로젝트 차원으로 지원

행복을 향한 의지

테스트 케이스

Page 85: 행복한 개발을 위한_테스트_케이스

one more thing…

Page 86: 행복한 개발을 위한_테스트_케이스

테스트 케이스는

본 코드의 사용 샘플이다 .

코드작성자에게로의

첫 셀프 피드백이다 .

기타

Page 87: 행복한 개발을 위한_테스트_케이스

테스트 케이스의 효과

기타

- 수정 시의 생산성 향상

- 버그잡기가 빨라진다 .

- 시스템 구조가 좋아진다 .

- 리펙토링이 가능해 진다 .

- 전체 시스템의 이해 없이 부분의 수정이 가능하다 .

- 샘플로 활용된다 .

- 코드 리뷰 시의 부담이 준다 .

- 설계와 구현을 분리할 수 있다 .

Page 88: 행복한 개발을 위한_테스트_케이스

Kent Beck

“ 나는 훌륭한 프로그래머는 아니다 .

그냥 훌륭한 습관을 가지고 있는

좋은 프로그래머이다 .”

기타

Page 89: 행복한 개발을 위한_테스트_케이스

감사합니다 .개발실 / BaaS 기술팀 / 임도형

[email protected] : @dhrim00