버그 발생은 어쩔 수 없다. 그런데 그 인지가 늦어지면 삽질스러워진다. 이를 방지하기 위한 유일한 방법은 오직 테스트 케이스 뿐이다.

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