[H3 2012] 행복한 개발을 위한 테스트 켶이스
Download as PPTX, PDF10 likes1,661 views
H3 2012 발표자료 행복한 개발을 위한 테스트 켶이스 -KTH 임도형
[H3 2012] 행복한 개발을 위한 테스트 켶이스
- 1. 행복한 개발을 위한 테스트 켶이스 BaaS 기술팀 I 임도형
- 2. 삽질이 싫어요 임도형 개발 문화, 삽질 증오
- 3. 삽질이 싫어요
- 4. 삽질이 싫어요 개발 경력 15년 쯤. 개발로 먹고 살고 싶고. 그것도 행복하게.
- 5. 삽질이 싫어요 행복한 개발을 하고 싶다. 쫌 가치 있는 생산성 있게 머리 쓰는 똘똘한
- 6. 삽질이 싫어요 그런데 삽질이 날Ħ
- 7. 삽질이 싫어요 버그 때문? 버그 잡이가 삽질?
- 8. 삽질이 싫어요 버그는 당연. 버그잡이는 개발의 일부. 버그잡이가 삽질은 아닙니다.
- 9. 삽질이 싫어요 하지만, 삽질스런 버그잡이는 피하고 싶다.
- 10. 삽질이 싫어요 코드 수정/추가 & 버그 발생(숨어있는)
- 11. 삽질이 싫어요 버그 기존 코드에서 추가 코드에서
- 12. 삽질이 싫어요 그리고 버그 인지
- 13. 삽질이 싫어요 발생과 인지 간격이 멀수록 삽질스러워 진다.
- 14. 삽질이 싫어요 빠른 버그 인지! 행복한 개발의 핵심.
- 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