[H3 2012] 행복한 개발을 위한 테스트 케이스

KTH, 케이티하이텔
KTH, 케이티하이텔KTH, 케이티하이텔
행복한 개발을
위한
테스트 케이스
BaaS 기술팀 I 임도형
삽질이 싫어요




    임도형


개발 문화, 삽질 증오
삽질이 싫어요
삽질이 싫어요




 개발 경력 15년 쯤.

개발로 먹고 살고 싶고.

 그것도 행복하게.
삽질이 싫어요




행복한 개발을 하고 싶다.
 쫌 가치 있는
 생산성 있게
 머리 쓰는 똘똘한
삽질이 싫어요




 그런데
삽질이 날…
삽질이 싫어요




  버그 때문?

버그 잡이가 삽질?
삽질이 싫어요




    버그는 당연.

 버그잡이는 개발의 일부.

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




   하지만,
삽질스런 버그잡이는
  피하고 싶다.
삽질이 싫어요




 코드 수정/추가
     &
버그 발생(숨어있는)
삽질이 싫어요




 버그

기존 코드에서

추가 코드에서
삽질이 싫어요




그리고 버그 인지
삽질이 싫어요




 발생과 인지
간격이 멀수록
삽질스러워 진다.
삽질이 싫어요




 빠른 버그 인지!


행복한 개발의 핵심.
삽질이 싫어요




영향도 분석?

불가능하다.
삽질이 싫어요




 영향도 분석?


어려운 것이 아니라
 불가능하다.
삽질이 싫어요




유일한 방법은

  오직

테스트 케이스
삽질이 싫어요




테스트 케이스의 목적

 새로운 버그의 발생을
   즉시 파악.
테스트 케이스
테스트 케이스




   테스트 코드?

작업 후 동작 확인 위한 코드
테스트 케이스




    테스트 코드?

보통은 System.out.println()

  혹은 직접 손과 눈으로
테스트 케이스




   테스트 코드는
테스트 케이스가 아니다.

버그의 발생을 파악할 수 없다.
테스트 케이스




JUnit 쓰면 테스트 케이스?


그럼 뭐가 테스트 케이스?
테스트 케이스




버그 발생 파악할 수 있어야
     을
    테스트 케이스
테스트 케이스




언제나 정상동작을
 확인할 수 있어야

내일도   모레도   1년뒤에도
테스트 케이스




재사용 가능해야
테스트 케이스
테스트 케이스




 손으로 해야 한다면

    확인 안한다.

시간 , 복잡 , 게으름 , 몰라서
테스트 케이스




자동화 가능해야
테스트 케이스
테스트 케이스




테스트 케이스라 칠라믄

  재사용 가능해야

  자동화 가능해야
테스트 케이스




     테스트 케이스

  수정된/추가된 코드로 인하여
기존 코드에 버그가 발생하지 않았음을
보장할 수 있는 효율적인 유일한 방법.
테스트 케이스




시스템 테스트, 혹은 QA

  효율적이지 않다.

  최소한의 대응이다.
테스트 케이스




  개발자 스스로가
    지금, 전부
실행시킬 수 있어야 한다.
테스트 케이스




테스트 케이스 작성은
추가적인 작업이 아니다.
테스트 케이스




뭔가 수정되었다면
수정된 것의 동작
기존의 것의 동작
 확인은 당연
테스트 케이스




추가되는 테스트 케이스

추가된 코드 동작 확인
추후 기존 코드 동작 확인
테스트 케이스




테스트 케이스는

재사용 가능해야

자동화 가능해야
목숨 걸고
지켜야
목숨 걸고 지켜야




방치된 실패 1개
전체 실패와 같다.
목숨 걸고 지켜야




  실패 1개가 있었으면
테스트 케이스를 아예 안 돌린다.
작업한 코드를 검증하지 않는다.
신규 버그를 알지 못한다.
심지어 버그를 알고도 커밋한다.
목숨 걸고 지켜야




100 - 1 = 0
      from http://www.creativereview.co.uk/cr-blog/2012/july/alex-chinneck-smashed-windows
목숨 걸고 지켜야




    커밋의 조건
    컴파일 성공
    테스트 전부 성공
?   컴파일 경고 없고
?   커버리지 만족
목숨 걸고 지켜야




컴파일 경고와
커버리지도
 마찬가지
행복하지 않은 현실
행복하지 않은 현실




 테스트 케이스 없~다
 가짜 테스트 케이스
실패하는 테스트 케이스
깨지기 쉬운 테스트 케이스
행복하지 않은 현실




 테스트 케이스 없~다

“일정이 너무 빡빡해서…”
“본 코드 짤 시간도…”
행복하지 않은 현실




 가짜 테스트 케이스

“테스트 코드 있잖아…”
“눈으로 확인했는데…”
행복하지 않은 현실




깨지기 쉬운 테스트 케이스

“안 깨지게 하려면,
손이 너무 많이 가…”
행복하지 않은 현실




“나만 열심히 해 봤자…”

“어차피 뒤집힐텐데…”

“자동화 하기 어려워…”
행복하지 않은 현실




테스트 케이스는
삽질 방지하자는 것
행복하려면
행복하려면




   개발자가
열심히 작성하면 된다?
행복하려면




프로젝트 차원으로 지원해야
  일정
  테스트 용이한 아키텍처
  편의성 있는 프레임웤
  개발자 지원
행복하려면




  프로젝트 차원?

개발자 개인의 책임이 아닌
관리자, 경영자의 의지
행복하려면 - 일정




관리자, 경영자를
깨우치게 해야
행복하려면 - 일정




    상상해 봅시다.
외국 어느 SW 회사에 입사.
빵빵한 테스트 케이스.
다운받아 작업 전에 실행해보니 전체 성공.
테스트 케이스로 타 모듈 사용 방법 파악.
기능 추가 후 새 테스트 케이스 추가.
전체 실행하니, 저쪽에서 실패.
직관적으로 원인 깨닫고 보완.
행복하려면 - 일정




          현실은
국내 어느 SW 회사에 입사.
테스트 케이스 전무.
다운받아 작업 전에… 실행해 볼것 없고.
빈약한 문서에 코드 보며 타 모듈 파악에 헉헉.
기능 추가 후 동작확인을 눈으로 확인.
3달 후 버그 리포팅.
재현, 분석, 삽질로 처리.
행복하려면 - 일정




             비용?
상상 :     테스트 케이스 작성 비용
       + 순간적 버그 픽스 비용(~=0)


현실 :     0
       + 추후 버그 픽스 비용
       + more, more
행복하려면 - 일정




일정은 어떻게든
극복될 것 같습니다.


비용이란 측면에서
행복하려면 - 아키텍처




   한 곳 수정하면
온갖 곳 다 신경 써야 하는.

   하나 작성하려면
온갖 모듈 다 로딩해야 하는.
행복하려면 - 아키텍처




  아키텍처의 문제

  모듈 간에 너무 끈끈

테스트 편의성 고려하지 않은
행복하려면 - 아키텍처




각 모듈 간의 의존성 제거

  Dependency Injection
행복하려면 - 아키텍처




테스트 용이하도록

 시스템 아키텍처
 서브 프로젝트 간 관계

 패키징 방법
행복하려면 - 프레임웤




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

   기반 전제에 기인
 개발자 개인이 극복 어렵다.
행복하려면 - 프레임웤




프레임웤으로 지원해야

   JUnit만으론 부족
테스트 케이스 개발이 편해야
행복하려면 - 프레임웤




테스트를 위한 프레임웤도
개발 범위에 포함되어야 한다.
행복하려면 – 개발자 지원




개발자 지원?
행복하려면 – 개발자 지원




#H3에서 느끼게 하자.


 기술적인 것이 아니다.
믿음과 경험, 감동, 습관.
행복하려면




프로젝트 차원에서
  지원하자.
행복하려면




그보다 중요한 것은
 개발자의 의지
유용할 수 있는
유용할 수 있는




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

  기반 데이터를 전제 X
  실행 순서를 전제 X
  리소스를 공유 X
   DB   설정파일
유용할 수 있는




Mock 서브시스템(DBMS)



테스트 시 디비를 구축.
디비 스키마도 버전 관리.
유용할 수 있는




Mock 서브시스템(Cassandra)




 테스트 시 Cassandra를 구동.
유용할 수 있는




각 테스트 케이스별 리소스
유용할 수 있는




      설정 오버라이딩
   테스트만을 위한 사항만 설정
  시스템 기본 설정
                 테스트 케이스의 설정




custom xml, properties도 오버라이딩.
유용할 수 있는




테스트 지원 프레임웤?

리소스 default 로딩
오버라이딩한 설정 로딩
구동 시 Mock 서브시스템 구동
유용할 수 있는




메소드 이름을 한글로
유용할 수 있는




요구사항 이름의 테스트 케이스
유용할 수 있는




Jetty를 사용한 시스템 테스트

   embeddable WAS

   패키징 없이 테스트
유용할 수 있는




시스템 테스트도
통합테스트도
자동화해야 한다.
유용할 수 있는




깨진 테스트 케이스,
  차라리 삭제.
유용할 수 있는




깨지기 쉬운 테스트 케이스,
     커밋 전
  리뷰를 통해 보완.
정리
테스트 케이스




행복하기 위한 필수
재사용, 자동화되어야
프로젝트 차원으로 지원
행복을 향한 의지
one more thing…
기타




  테스트 케이스는
본 코드의 사용 샘플이다.
 코드작성자에게로의
 첫 셀프 피드백이다.
기타




테스트 케이스의 효과
 - 수정 시의 생산성 향상
 - 버그잡기가 빨라진다.
 - 시스템 구조가 좋아진다.
 - 리펙토링이 가능해 진다.
 - 전체 시스템의 이해 없이 부분의 수정이 가능하다.
 - 샘플로 활용된다.
 - 코드 리뷰 시의 부담이 준다.
 - 설계와 구현을 분리할 수 있다.
기타




      Kent Beck
“나는 훌륭한 프로그래머는 아니다.
그냥 훌륭한 습관을 가지고 있는
   좋은 프로그래머이다.”
감사합니다.
개발실 / BaaS 기술팀 / 임도형
   dhrim@kthcorp.com
    twitter : @dhrim00
1 von 89

Más contenido relacionado

Más de KTH, 케이티하이텔(20)

[H3 2012] UX, 애자일하고 싶어요[H3 2012] UX, 애자일하고 싶어요
[H3 2012] UX, 애자일하고 싶어요
KTH, 케이티하이텔2.6K views
[H3 2012] Instant Prototyping with ROR[H3 2012] Instant Prototyping with ROR
[H3 2012] Instant Prototyping with ROR
KTH, 케이티하이텔1.3K views
[H3 2012] Local based SNS를 이용한 타겟 마케팅[H3 2012] Local based SNS를 이용한 타겟 마케팅
[H3 2012] Local based SNS를 이용한 타겟 마케팅
KTH, 케이티하이텔11.8K views
[H3 2012] 오픈소스로 개발 실력 쌓기[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기
KTH, 케이티하이텔47.9K views

[H3 2012] 행복한 개발을 위한 테스트 케이스