테스트 기발 개발, TBD(Test based developement)
- 1. (주)엑셈 / 임도형
- 4. • 업무를 통해 개인의 실력이 향상. • 업무의 결과가 좋다. 일정과 코드. • 반복적이거나 지겹지 않다. • 도전적이고 성취감 있다. • 대상 업무를 선택할 수 있다. • 대상 프로젝트를 선택할 수 있다. • 매출이 잘된다. • 버그가 적다. • 신 기술을 적용해 볼 수 있다. • 이직이 쉽다. • 연봉이 잘 오른다. • 외부에 이름이 알려진다. 이상적인 개발
- 5. • 적절한 일정. • 업무와 무관한 공부도 할수 있고. • 외부 세미나도 참석하고. • 미팅 적고. • 문서 작성 적고. • 프로젝트도, 팀도, 회사도 안정되고. • 동료와 얘기가 통하고. • 인사 평가 신경 안쓰고. • 당연한 퇴근, 주말, 취미. 이상적인 개발
- 6. • 전부 반대 • 항상 같은 일, 지겹고 반복적이고. • 코드 파악 어렵고, 문서 없고, 코드 고치면 버그 생기고. • 항상 일정 쪼이고, 야근에, 피곤에 • 매출 적고, 프로젝트/팀/회사 위태. 연봉 적고, 안오르고. • 쪼이고, 쪼고, 짜증내고, 싸우고. • 실력보단 인맥. 사람에 충성. • 공부할 시간 없고, 세미나 스터디 외면. • 이직할 생각만, 하지만 이직은 어렵고. 현실은
- 9. 이상은 그냥 꿈?
- 10. 이상은 그냥 꿈? 존재는 하는 것 같다.
- 11. 말로만 들었지만 Google, Amazon, …
- 12. 필수적인 테스트 케이스 성공적인 모든 SW의 공통점. 테스트 케이스 없이는 머징 불가
- 13. 이상으로 가는 핵심 가장 효과가 크다. 반대로 테스트 케이스 없이는 현실 탈출 불가.
- 15. 변경했으면 확인하자
- 17. 자동으로 확인하는 코드 그것이 테스트 케이스
- 18. 언어와 무관 JUnit과 무관
- 24. 테크닉이 아니다. JUnit은 누구나 안다.
- 25. 테스트 케이스를 가지고 일하는 습관이다.
- 26. 머리가 아닌 몸이 익혀야 한다.
- 27. 작업을 했는데, 테스트 케이스로 확인 못하면 못 견디도록.
- 28. 약간의 테크닉, 노하우, 팁 물론 있다.
- 29. 예전에 무시했던 maven, git과 같다. 이젠 없으면 불가한.
- 30. 문화는 사람 사이에 존재 종이 위에 있지 않다.
- 33. • 코드 체크아웃 • 테스트 케이스 성공 확인 • 코딩(본 코드 + 테스트 케이스) • 작성한 테스트 케이스 성공 확인 • 모든 테스트 케이스 성공 확인 • 문서 작성 • 커밋, 머지 리퀘스트 생성 • 코드 리뷰 • 머지 실행 순서
- 34. • 코드를 체크 아웃 • 기존 테스트 케이스의 성공 확인 • 실패하면 이를 공지하고 픽스를 요청한다. • 픽스 후 다시 체크아웃하여 성공을 확인한다. 코드 체크 아웃과 테스트 케이스 확인
- 35. 실패한 테스트 케이스 1개
- 36. • 현재 실패하는 테스트 케이스가 기존의 것인 지, 수정된 것에 기 인한것인 지 모른다. • 기존의 것이 전부 성공했다면, 무조건 수정된 것에 의한 것이다. 기존에 깨진 테스트 케이스가 있으면
- 37. 전체 성공이 작성보다 더 중요하다
- 38. • 커밋 전에 전체 실행해서 성공을 확인 • 전체 실행해서 성공 확인하는 거… 생각보다 아주 어렵다. • 그리고 CI 서버가 필요. • CI 서버 없이 테스트 케이스로 개발하기 어렵다. 항상 성공을 지키려면
- 39. • 본 코드를 작성하면, 하여간 동작을 확인해야 한다. • 이를 테스트 케이스로 한다. • 작성한 테스트 케이스는 당연히 성공해야 하고 본 코드와 테스트 케이스 작성
- 40. • 작성한 테스트 케이스외에, 기존에 있던 모든 테스트 케이스의 성공을 확인한다. • 실패한다면, 하여간에 수정된 것에 기인한 것이다. • 이 과정을 누락하면, 타인이 작업을 못한다. 모든 테스트 케이스 성공 확인
- 41. • 무엇을 했는 지 문서만 보고도 파악할 수 있어야. • 코드를 보고 파악하는 것은 무척 어렵다. 특히 여러 파일에 걸쳐 작업된 경우는. • 하여간에 코드만을 보고 이해할 수 없는 것은 전부 기술되어야 한다. • 작성하는 문서는 코드 리뷰를 목적으로 한다. • 포멧은 상관없다. 문서 작성
- 42. • 커밋 하기 전에 변경된 부분 하나하나 검토한다. • 그러면서 기억안나는, 코드 변경 이유가 생각나고 이를 문서에 적어주면 좋다. 문서 작성 팁
- 43. • 전체 작업 내용을 요약 • 변경된 파일 리스트와 각 변경 요약 • 세부 작업의 설명 • 실패하고 고생한 사항. • 추후 진행할 TODO 문서에 포함될 내용
- 44. • 작성한 문서를 첨부. 머지 리퀘스트 생성
- 45. • 머지 리퀘스트에 첨부된 문서를 가지고 작업을 설명. • 코딩 완료 여부는 테스트 케이스 리스트로 판단한다. • 충분한 테스트 케이스가 있고, 테스트 케이스가 충실히 구현되어 다면, 본 코드의 구현 여부는 믿을 수 있다. • 이후 본 코드의 리뷰는 로직 보다는 단지 컨벤션만 보면 된다. 코드 리뷰
- 46. • 내가 타인이 작업한 결과를 이어서 작업할 정도로 정리가 잘 되 었는가. • 문서와 코드가 내가 이해할 정도로 잘 정리되었는가. • 파악할 사항 • 테스트 케이스의 내용 • 코드 컨벤션. • 대면 코드리뷰가 아닌 online 코드리뷰 만으로 이해가 되어야 한 다. 코드 리뷰의 기준
- 47. • 코드 리뷰. • 타인이 이해하고 이후 작업할 수 있다는 확신이 들도록 작업을 설명하는 것. • 그리고 최종적으로 머징. 문서의 목적
- 48. • 언급된 사항들을 수정한다. • 혹은 언급된 사항에 대한 설명을 한다. 코드 리뷰 사항 반영
- 49. • 프로젝트 소유자가 코드리뷰와 그 반영을 확인하고 머징. 머징
- 51. 부작용이 방지된다. 수정으로 인해 발생하는 버그를 드러내게 한다. 유일한 방법.
- 52. 코드 리뷰가 쉬워진다. 로직을 상세히 파악 안해도 된다. 안 싸워도 된다.
- 53. 코드 파악이 쉬워진다. 특정 단위의 실행 코드가 존재.
- 54. 코드 사용 샘플 테스크 케이스 코드 자체가 사용 샘플이다. 호출 하기 위한 값들이 코드에 보인다.
- 55. 본 코드의 구조 향상 테스트 케이스를 작성하려면 본 코드가 의존성 없이 잘 분리되어 있어야 한다.
- 56. 설계 향상 단위로 테스트 케이스를 작성하려면 단위로 쪼개서 설꼐해야 한다.
- 57. 버그 부활 방지 한번 픽스된 버그는 그 픽스한 테스트 케이스가 커버한다. 부활되어(테스트 케이스 실패하여) 커밋 될 수 없다.
- 58. 전체 이해 없이 부분 작업 가능 부분만 이해하고 수정해도, 이로 이한 부작용을 우려하지 않아도 된다.
- 59. • 기존 코드 파악이 어렵다. • 작업을 진행해도 불안하다. • 버그가 발생해도 모른다. • 긴 시간 후에 고객이 버그를 리포팅한다. • 리포팅된 정보만으로 버그를 유추한다. • 분석에 오랜 시간이 걸린다. • 버그 현상을 재현하기 어렵다. 못하는 경우도 있다. • 유추한 사항으로 원인을 상상한다. • 상상한 대로 코드를 수정하고 배포. • 하지만 버그를 픽스했는지 확신하지 못한다. 버그 발생과 픽스 - 테스트 케이스 없이
- 60. • 기존 코드 파악이 쉽다. • 수정 직후 기존 테스트 케이스가 실패하여 버그 출현을 파악한다. • 분석할 필요도 없이 직관적으로 픽스한다. 버그 발생과 픽스 - 테스트 케이스 있으면
- 62. 코딩은 오직 3가지 - 기능 추가 - 버그 픽스 - 리팩터링
- 63. • 추가한 기능의 동작을 확인하는 테스트 케이스를 작성한다. • 이후 코드의 수정으로 인한 버그는 이 테스트 케이스로 커버된다. 기능 추가
- 64. • 버그를 재현하는 테스트 케이스를 작성한다. • 작성한 테스트 케이스는 리포팅된대로 실패한다. • 이후 본코드를 픽스하여 테스트 케이스가 성공하도록 한다. • 이후 코드의 수정으로 인한 버그 부활은 이 테스트 케이스로 커 버된다. 버그 픽스
- 65. 리팩터링 기능은 변경하지 않고 코드 모양만 개선하는 작업
- 66. 테스트 케이스 없는 리팩터링? 하지마라! 하지마라!
- 67. 테스트 케이스 있다면? 리팩터링? 자주 하라! 맘껏 하라!
- 69. 목적은 생산성
- 70. 개발 생산성은 다양한 사항과 관련. 그중 코드 자체도.
- 71. 코딩은 오직 3가지 - 기능 추가 - 버그 픽스 - 리팩터링
- 72. 모두 기존 코드를 가지고 시작한다.
- 74. 기존 코드 읽기 쉬운 것이 품질이다.
- 75. 생산성을 위한 읽기 쉬운 코드. 가독성이 품질의 기준.
- 76. 컨벤션의 기준은 가독성
- 77. • 이름이 중요. • 클래스, 변수, 함수 • 하나의 함수는 20라인 미만 • 인덴트는 2개 까지만 • 주석 없이 변수와 메소드 이름만으로 읽히는. • 로직을 이해 안해도 줄줄 읽어 내려갈 수 있는. 가독성이 높으려면
- 78. 이 외의 것은 중요하지 않다.
- 80. 개발은 특정 단위 기준으로 함수, 클래스, 패키지, 모듈, 컴퍼넌트, 서브 시스템, 시스템. 하여간에 특정단위로 개발한다.
- 81. 단위? 요구사항을 가지고 개발하고 완료 판단하는 단위.
- 82. 단위, 요구사항? 그 단위가 특정 기능(요구사항)을 만족하면 개발이 완료된 것이다. 함수건, 클래스건, 컴퍼넌트건, 시스템이건
- 83. 단위와 인터페이스 모든 요구사항은 입출력을 기반으로 한다. 그 입출력의 정의가 인터페이스 이다.
- 84. 단위별로 독립적이고 오직 인터페이스로만 상호 동작
- 85. 단위와 인터페이스 그리고 테스트 케이스 대상 인터페이스의 입출력의 동작을 테스트 케이스로 확인
- 86. 바람직한 작업 단위는 클래스 5개 정도. 3일 작업량
- 87. 테스트 케이스 작성은 단위의 크기로 한다. 작은 단위 아니면 어렵다.
- 88. 레거시의 경우 그 단위가 아주 크다. 시스템 급.
- 89. 적용을 위해 내부를 리팩터링 해야 한다.
- 90. 시스템 단위를 컴퍼넌트 단위로 쪼개는
- 91. 리팩터링 위한 테스트 케이스 작성 필요
- 92. • 시스템 밖에서의 입출력으로 하는 테스트 케이스를 작성. • 시스템의 내부를 수정해도 그 정상 동작을 확인하기 위한. • 시스템의 크기 만큼 충반한 양의 테스트 케이스 작성 필요. • 충분의 기준. • 임의의 코드에서 인위적으로 버그를 만들고, 실패 하는 지 확인. • 80%정도면 아주 양호. 시스템의 리팩터링위한 테스트 케이스
- 93. 테스트 케이스를 가지고 리팩터링 내부를 작은 단위로 쪼개는 것이 목적
- 94. • 처음부터 너무 작게 쪼개는 것은 힘들다. • 5,6개 정도의 기능단위로 구분하고, 퍼져 있는 기능을 각 단위로 응축. • 이렇게 하기 위해서는 구분 후에 각 단위간의 인터페이스를 정의. • 이렇게 쪼개고 나서는 각 단위별로 정의한 인터페이스를 가지고 테스트 케이스를 작성. • 그리고 실 작업(기능 추가, 버그 픽스)를 위한 단위 만큼 쪼개질때 까지 해당 단위의 쪼개기 리팩터링 반복 내부 쪼개기
- 95. 초기 레거시 시스템
- 96. 전체 시스템 대상 테스트 케이스
- 97. 시스템 내부 리팩터링
- 98. 모듈 대상 테스트 케이스 작성
- 99. 모듈 내부 리팩터링
- 101. 요구사항 요구사항 변경되면 본 코드와 더불어 테스트 케이스도 변경해야. 요구사항이 어느정도 튼튼해야 한다.
- 102. 일정 테스트 케이스 작성에 당연 시간 소요된다. 득과 실을 판단할 수 있어야 한다.
- 103. 거부감 무언가 도입해서 잘된 경험이 없다.
- 104. 학습 시간 몸에 익기까지 최소 3달 필요.
- 105. 지속적 노력 지식이 아니라 몸에 익혀야 한다.
- 106. 극복하려면 개발자, 관리자, 경영자 모두 같이 노력해야 한다.
- 107. 개발자는, 지속적인 노력 다 자기 역량이 된다.
- 108. 관리자는, 요구사항, 일정 관리 문화가 될 때 까지 생산성 떨어진다
- 109. 경영자는, 믿고 지원. 조직의 생산성을 역량을 높이는 것이다.