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

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

삽질이 싫어요

임도형

개발 문화 , 삽질 증오

삽질이 싫어요

삽질이 싫어요

개발 경력 15 년 쯤 .

개발로 먹고 살고 싶고 .

그것도 행복하게 .

행복한 개발을 하고 싶다 .

쫌 가치 있는

생산성 있게

머리 쓰는 똘똘한

삽질이 싫어요

그런데

삽질이 날…

삽질이 싫어요

버그 때문 ?

삽질이 싫어요

버그 잡이가 삽질 ?

버그는 당연 .

삽질이 싫어요

버그잡이는 개발의 일부 .

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

하지만 ,

삽질스런 버그잡이는

피하고 싶다 .

삽질이 싫어요

버그 발생 ( 숨어있는 )

삽질이 싫어요

코드 수정 / 추가

&

버그

삽질이 싫어요

기존 코드에서

추가 코드에서

삽질이 싫어요

그리고 버그 인지

간격이 멀수록

삽질스러워 진다 .

삽질이 싫어요

발생과 인지

빠른 버그 인지 !

삽질이 싫어요

행복한 개발의 핵심 .

영향도 분석 ?

삽질이 싫어요

불가능하다 .

영향도 분석 ?

삽질이 싫어요

어려운 것이 아니라

불가능하다 .

유일한 방법은

삽질이 싫어요

오직

테스트 케이스

테스트 케이스의 목적

삽질이 싫어요

새로운 버그의 발생을

즉시 파악 .

테스트 케이스

테스트 코드 ?

테스트 케이스

작업 후 동작 확인 위한 코드

테스트 코드 ?

테스트 케이스

보통은 System.out.println()

혹은 직접 손과 눈으로

테스트 코드는

테스트 케이스가 아니다 .

테스트 케이스

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

JUnit 쓰면 테스트 케이스 ?

테스트 케이스

그럼 뭐가 테스트 케이스 ?

을 파악할 수 있어야

테스트 케이스

테스트 케이스

버그 발생

언제나 정상동작을

확인할 수 있어야

테스트 케이스

내일도 모레도 1 년뒤에도

재사용 가능해야

테스트 케이스

테스트 케이스

손으로 해야 한다면

테스트 케이스

시간

확인 안한다 .

, 복잡, 게으름, 몰라서

자동화 가능해야

테스트 케이스

테스트 케이스

테스트 케이스라 칠라믄

테스트 케이스

재사용 가능해야

자동화 가능해야

테스트 케이스

테스트 케이스

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

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

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

시스템 테스트 , 혹은 QA

테스트 케이스

효율적이지 않다 .

최소한의 대응이다 .

개발자 스스로가

지금 , 전부

실행시킬 수 있어야 한다 .

테스트 케이스

테스트 케이스 작성은

추가적인 작업이 아니다 .

테스트 케이스

뭔가 수정되었다면

테스트 케이스

확인은 당연

수정된 것의 동작

기존의 것의 동작

추가되는 테스트 케이스

테스트 케이스

추가된 코드 동작 확인

추후 기존 코드 동작 확인

테스트 케이스는

테스트 케이스

가능해야

자동화

재사용

가능해야

목숨 걸고 지켜야

방치된 실패 1 개

목숨 걸고 지켜야

전체 실패와 같다 .

실패 1 개가 있었으면

목숨 걸고 지켜야

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

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

신규 버그를 알지 못한다 .

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

100

목숨 걸고 지켜야

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

- 1= 0

커밋의 조건

목숨 걸고 지켜야

컴파일 성공

테스트 전부 성공

컴파일 경고 없고

커버리지 만족

?

?

컴파일 경고와

커버리지도

마찬가지

목숨 걸고 지켜야

행복하지 않은 현실

테스트 케이스 없 ~ 다

행복하지 않은 현실

실패하는 테스트 케이스

깨지기 쉬운 테스트 케이스

가짜 테스트 케이스

행복하지 않은 현실

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

“ 본 코드 짤 시간도…”

테스트 케이스 없 ~ 다

행복하지 않은 현실

“ 테스트 코드 있잖아…”

“ 눈으로 확인했는데…”

가짜 테스트 케이스

행복하지 않은 현실

“ 안 깨지게 하려면 ,

손이 너무 많이 가…”

깨지기 쉬운 테스트 케이스

행복하지 않은 현실

“ 나만 열심히 해 봤자…”

“ 어차피 뒤집힐텐데…”

“ 자동화 하기 어려워…”

테스트 케이스는

삽질 방지하자는 것

행복하지 않은 현실

행복하려면

개발자가

열심히 작성하면 된다 ?

행복하려면

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

행복하려면

일정

테스트 용이한 아키텍처

편의성 있는 프레임웤

개발자 지원

프로젝트 차원 ?

행복하려면

개발자 개인의 책임이 아닌

관리자 , 경영자의 의지

관리자 , 경영자를

깨우치게 해야

행복하려면 - 일정

상상해 봅시다 .

행복하려면 - 일정

외국 어느 SW 회사에 입사 .

빵빵한 테스트 케이스 .

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

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

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

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

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

현실은

행복하려면 - 일정

국내 어느 SW 회사에 입사 .

테스트 케이스 전무 .

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

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

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

3 달 후 버그 리포팅 .

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

비용 ?

행복하려면 - 일정

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

+ 순간적 버그 픽스 비용

(~=0)

현실 : 0

+ 추후 버그 픽스 비용

+ more, more

일정은 어떻게든

극복될 것 같습니다 .

비용이란 측면에서

행복하려면 - 일정

한 곳 수정하면

온갖 곳 다 신경 써야 하는 .

행복하려면 - 아키텍처

하나 작성하려면

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

아키텍처의 문제

행복하려면 - 아키텍처

모듈 간에 너무 끈끈

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

각 모듈 간의 의존성 제거

행복하려면 - 아키텍처

Dependency Injection

시스템 아키텍처

행복하려면 - 아키텍처

서브 프로젝트 간 관계

패키징 방법

테스트 용이하도록

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

행복하려면 - 프레임웤

기반 전제에 기인

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

프레임웤으로 지원해야

행복하려면 - 프레임웤

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

JUnit 만으론 부족

테스트를 위한 프레임웤도

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

행복하려면 - 프레임웤

행복하려면 – 개발자 지원

개발자 지원 ?

#H3 에서 느끼게 하자 .

행복하려면 – 개발자 지원

기술적인 것이 아니다 .

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

프로젝트 차원에서

지원하자 .

행복하려면

그보다 중요한 것은

개발자의 의지

행복하려면

유용할 수 있는

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

유용할 수 있는

기반 데이터를 전제 X

실행 순서를 전제 X

리소스를 공유 X

DB 설정파일

Mock 서브시스템 (DBMS)

유용할 수 있는

테스트 시 디비를 구축 .

디비 스키마도 버전 관리 .

Mock 서브시스템 (Cassandra)

유용할 수 있는

테스트 시 Cassandra 를 구동 .

각 테스트 케이스별 리소스

유용할 수 있는

설정 오버라이딩

유용할 수 있는

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

테스트 케이스의 설정

시스템 기본 설정

custom xml, properties 도 오버라이딩 .

테스트 지원 프레임웤 ?

유용할 수 있는

구동 시 Mock 서브시스템 구동

오버라이딩한 설정 로딩

리소스 default 로딩

메소드 이름을 한글로

유용할 수 있는

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

유용할 수 있는

Jetty 를 사용한 시스템 테스트

유용할 수 있는

패키징 없이 테스트

embeddable WAS

시스템 테스트도

통합테스트도

자동화해야 한다 .

유용할 수 있는

깨진 테스트 케이스 ,

차라리 삭제 .

유용할 수 있는

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

커밋 전

리뷰를 통해 보완 .

유용할 수 있는

정리

행복하기 위한 필수

재사용 , 자동화되어야

프로젝트 차원으로 지원

행복을 향한 의지

테스트 케이스

one more thing…

테스트 케이스는

본 코드의 사용 샘플이다 .

코드작성자에게로의

첫 셀프 피드백이다 .

기타

테스트 케이스의 효과

기타

- 수정 시의 생산성 향상

- 버그잡기가 빨라진다 .

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

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

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

- 샘플로 활용된다 .

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

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

Kent Beck

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

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

좋은 프로그래머이다 .”

기타

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

dhrim@kthcorp.comtwitter : @dhrim00