행복한 개발을위한테스트 케이스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
Upcoming SlideShare
Loading in …5
×

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

2,221 views

Published on

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

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,221
On SlideShare
0
From Embeds
0
Number of Embeds
501
Actions
Shares
0
Downloads
62
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

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

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

×