[H3 2012] 행복한 개발을 위한 테스트 케이스
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 1,986 views

H3 2012 발표자료

H3 2012 발표자료
행복한 개발을 위한 테스트 케이스
-KTH 임도형

Statistics

Views

Total Views
1,986
Views on SlideShare
1,493
Embed Views
493

Actions

Likes
1
Downloads
57
Comments
0

5 Embeds 493

http://h3.kthcorp.com 461
http://h3.paran.com 26
http://h3.localhost.com 4
http://211.62.44.161 1
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 1. 행복한 개발을위한테스트 케이스BaaS 기술팀 I 임도형
  • 2. 삽질이 싫어요 임도형개발 문화, 삽질 증오
  • 3. 삽질이 싫어요
  • 4. 삽질이 싫어요 개발 경력 15년 쯤.개발로 먹고 살고 싶고. 그것도 행복하게.
  • 5. 삽질이 싫어요행복한 개발을 하고 싶다. 쫌 가치 있는 생산성 있게 머리 쓰는 똘똘한
  • 6. 삽질이 싫어요 그런데삽질이 날…
  • 7. 삽질이 싫어요 버그 때문?버그 잡이가 삽질?
  • 8. 삽질이 싫어요 버그는 당연. 버그잡이는 개발의 일부.버그잡이가 삽질은 아닙니다.
  • 9. 삽질이 싫어요 하지만,삽질스런 버그잡이는 피하고 싶다.
  • 10. 삽질이 싫어요 코드 수정/추가 &버그 발생(숨어있는)
  • 11. 삽질이 싫어요 버그기존 코드에서추가 코드에서
  • 12. 삽질이 싫어요그리고 버그 인지
  • 13. 삽질이 싫어요 발생과 인지간격이 멀수록삽질스러워 진다.
  • 14. 삽질이 싫어요 빠른 버그 인지!행복한 개발의 핵심.
  • 15. 삽질이 싫어요영향도 분석?불가능하다.
  • 16. 삽질이 싫어요 영향도 분석?어려운 것이 아니라 불가능하다.
  • 17. 삽질이 싫어요유일한 방법은 오직테스트 케이스
  • 18. 삽질이 싫어요테스트 케이스의 목적 새로운 버그의 발생을 즉시 파악.
  • 19. 테스트 케이스
  • 20. 테스트 케이스 테스트 코드?작업 후 동작 확인 위한 코드
  • 21. 테스트 케이스 테스트 코드?보통은 System.out.println() 혹은 직접 손과 눈으로
  • 22. 테스트 케이스 테스트 코드는테스트 케이스가 아니다.버그의 발생을 파악할 수 없다.
  • 23. 테스트 케이스JUnit 쓰면 테스트 케이스?그럼 뭐가 테스트 케이스?
  • 24. 테스트 케이스버그 발생 파악할 수 있어야 을 테스트 케이스
  • 25. 테스트 케이스언제나 정상동작을 확인할 수 있어야내일도 모레도 1년뒤에도
  • 26. 테스트 케이스재사용 가능해야테스트 케이스
  • 27. 테스트 케이스 손으로 해야 한다면 확인 안한다.시간 , 복잡 , 게으름 , 몰라서
  • 28. 테스트 케이스자동화 가능해야테스트 케이스
  • 29. 테스트 케이스테스트 케이스라 칠라믄 재사용 가능해야 자동화 가능해야
  • 30. 테스트 케이스 테스트 케이스 수정된/추가된 코드로 인하여기존 코드에 버그가 발생하지 않았음을보장할 수 있는 효율적인 유일한 방법.
  • 31. 테스트 케이스시스템 테스트, 혹은 QA 효율적이지 않다. 최소한의 대응이다.
  • 32. 테스트 케이스 개발자 스스로가 지금, 전부실행시킬 수 있어야 한다.
  • 33. 테스트 케이스테스트 케이스 작성은추가적인 작업이 아니다.
  • 34. 테스트 케이스뭔가 수정되었다면수정된 것의 동작기존의 것의 동작 확인은 당연
  • 35. 테스트 케이스추가되는 테스트 케이스추가된 코드 동작 확인추후 기존 코드 동작 확인
  • 36. 테스트 케이스테스트 케이스는재사용 가능해야자동화 가능해야
  • 37. 목숨 걸고지켜야
  • 38. 목숨 걸고 지켜야방치된 실패 1개전체 실패와 같다.
  • 39. 목숨 걸고 지켜야 실패 1개가 있었으면테스트 케이스를 아예 안 돌린다.작업한 코드를 검증하지 않는다.신규 버그를 알지 못한다.심지어 버그를 알고도 커밋한다.
  • 40. 목숨 걸고 지켜야100 - 1 = 0 from http://www.creativereview.co.uk/cr-blog/2012/july/alex-chinneck-smashed-windows
  • 41. 목숨 걸고 지켜야 커밋의 조건 컴파일 성공 테스트 전부 성공? 컴파일 경고 없고? 커버리지 만족
  • 42. 목숨 걸고 지켜야컴파일 경고와커버리지도 마찬가지
  • 43. 행복하지 않은 현실
  • 44. 행복하지 않은 현실 테스트 케이스 없~다 가짜 테스트 케이스실패하는 테스트 케이스깨지기 쉬운 테스트 케이스
  • 45. 행복하지 않은 현실 테스트 케이스 없~다“일정이 너무 빡빡해서…”“본 코드 짤 시간도…”
  • 46. 행복하지 않은 현실 가짜 테스트 케이스“테스트 코드 있잖아…”“눈으로 확인했는데…”
  • 47. 행복하지 않은 현실깨지기 쉬운 테스트 케이스“안 깨지게 하려면,손이 너무 많이 가…”
  • 48. 행복하지 않은 현실“나만 열심히 해 봤자…”“어차피 뒤집힐텐데…”“자동화 하기 어려워…”
  • 49. 행복하지 않은 현실테스트 케이스는삽질 방지하자는 것
  • 50. 행복하려면
  • 51. 행복하려면 개발자가열심히 작성하면 된다?
  • 52. 행복하려면프로젝트 차원으로 지원해야 일정 테스트 용이한 아키텍처 편의성 있는 프레임웤 개발자 지원
  • 53. 행복하려면 프로젝트 차원?개발자 개인의 책임이 아닌관리자, 경영자의 의지
  • 54. 행복하려면 - 일정관리자, 경영자를깨우치게 해야
  • 55. 행복하려면 - 일정 상상해 봅시다.외국 어느 SW 회사에 입사.빵빵한 테스트 케이스.다운받아 작업 전에 실행해보니 전체 성공.테스트 케이스로 타 모듈 사용 방법 파악.기능 추가 후 새 테스트 케이스 추가.전체 실행하니, 저쪽에서 실패.직관적으로 원인 깨닫고 보완.
  • 56. 행복하려면 - 일정 현실은국내 어느 SW 회사에 입사.테스트 케이스 전무.다운받아 작업 전에… 실행해 볼것 없고.빈약한 문서에 코드 보며 타 모듈 파악에 헉헉.기능 추가 후 동작확인을 눈으로 확인.3달 후 버그 리포팅.재현, 분석, 삽질로 처리.
  • 57. 행복하려면 - 일정 비용?상상 : 테스트 케이스 작성 비용 + 순간적 버그 픽스 비용(~=0)현실 : 0 + 추후 버그 픽스 비용 + more, more
  • 58. 행복하려면 - 일정일정은 어떻게든극복될 것 같습니다.비용이란 측면에서
  • 59. 행복하려면 - 아키텍처 한 곳 수정하면온갖 곳 다 신경 써야 하는. 하나 작성하려면온갖 모듈 다 로딩해야 하는.
  • 60. 행복하려면 - 아키텍처 아키텍처의 문제 모듈 간에 너무 끈끈테스트 편의성 고려하지 않은
  • 61. 행복하려면 - 아키텍처각 모듈 간의 의존성 제거 Dependency Injection
  • 62. 행복하려면 - 아키텍처테스트 용이하도록 시스템 아키텍처 서브 프로젝트 간 관계 패키징 방법
  • 63. 행복하려면 - 프레임웤깨지기 쉬운 테스트 케이스? 기반 전제에 기인 개발자 개인이 극복 어렵다.
  • 64. 행복하려면 - 프레임웤프레임웤으로 지원해야 JUnit만으론 부족테스트 케이스 개발이 편해야
  • 65. 행복하려면 - 프레임웤테스트를 위한 프레임웤도개발 범위에 포함되어야 한다.
  • 66. 행복하려면 – 개발자 지원개발자 지원?
  • 67. 행복하려면 – 개발자 지원#H3에서 느끼게 하자. 기술적인 것이 아니다.믿음과 경험, 감동, 습관.
  • 68. 행복하려면프로젝트 차원에서 지원하자.
  • 69. 행복하려면그보다 중요한 것은 개발자의 의지
  • 70. 유용할 수 있는
  • 71. 유용할 수 있는테스트 케이스가 튼튼하려면 기반 데이터를 전제 X 실행 순서를 전제 X 리소스를 공유 X DB 설정파일
  • 72. 유용할 수 있는Mock 서브시스템(DBMS)테스트 시 디비를 구축.디비 스키마도 버전 관리.
  • 73. 유용할 수 있는Mock 서브시스템(Cassandra) 테스트 시 Cassandra를 구동.
  • 74. 유용할 수 있는각 테스트 케이스별 리소스
  • 75. 유용할 수 있는 설정 오버라이딩 테스트만을 위한 사항만 설정 시스템 기본 설정 테스트 케이스의 설정custom xml, properties도 오버라이딩.
  • 76. 유용할 수 있는테스트 지원 프레임웤?리소스 default 로딩오버라이딩한 설정 로딩구동 시 Mock 서브시스템 구동
  • 77. 유용할 수 있는메소드 이름을 한글로
  • 78. 유용할 수 있는요구사항 이름의 테스트 케이스
  • 79. 유용할 수 있는Jetty를 사용한 시스템 테스트 embeddable WAS 패키징 없이 테스트
  • 80. 유용할 수 있는시스템 테스트도통합테스트도자동화해야 한다.
  • 81. 유용할 수 있는깨진 테스트 케이스, 차라리 삭제.
  • 82. 유용할 수 있는깨지기 쉬운 테스트 케이스, 커밋 전 리뷰를 통해 보완.
  • 83. 정리
  • 84. 테스트 케이스행복하기 위한 필수재사용, 자동화되어야프로젝트 차원으로 지원행복을 향한 의지
  • 85. one more thing…
  • 86. 기타 테스트 케이스는본 코드의 사용 샘플이다. 코드작성자에게로의 첫 셀프 피드백이다.
  • 87. 기타테스트 케이스의 효과 - 수정 시의 생산성 향상 - 버그잡기가 빨라진다. - 시스템 구조가 좋아진다. - 리펙토링이 가능해 진다. - 전체 시스템의 이해 없이 부분의 수정이 가능하다. - 샘플로 활용된다. - 코드 리뷰 시의 부담이 준다. - 설계와 구현을 분리할 수 있다.
  • 88. 기타 Kent Beck“나는 훌륭한 프로그래머는 아니다.그냥 훌륭한 습관을 가지고 있는 좋은 프로그래머이다.”
  • 89. 감사합니다.개발실 / BaaS 기술팀 / 임도형 dhrim@kthcorp.com twitter : @dhrim00