TDD, Test Driven Development

Test Driven Development, 2019, Republic of Korea

Transcript

1. TDD가 하고 싶어요 김지훈 [jazz] 
2. jazz • 당연한 이야기를 합니다
 • 저는 개발플랫폼셀에서 MoBiL을 만듭니다 • mobil CI/CD 서비스 • TDD가 하고 싶어요 
3. Do you know TDD? 
4. Do you know TDD? ׮
   ইदח
   ٜ࠙਷
   ৈӝ
   ৵
   ҅दחѢભ 
5. TDD • Test Driven Development
 테스트 주도 개발 • “결정과 피드백 사이의 갭에 대한 인식"
 간극을 조절하기 위한 테크닉 • 결정 - ‘이렇게 프로그래밍 해야지' • 피드백 - '이게 되네?' 혹은 '안되네?' 와 같은 피드백 
6. clean code that works 
7. (Short Version) TDD • Red (Fail) • Green (Success) • Blue (Refactor) 
8. (Short Version) TDD • Red (Fail) • 해결하려는 문제에 대한 테스트를 만들고,
 실행시켜서 Fail을 얻어낸다 • Green (Success) • 막 만든 test 를 최대한 쉽게 성공시킨다 • Blue (Refactor) • Green을 유지하면서 올바르게 리팩토링 한다.
 그리고 반복. 
9. 
10. Test First Development + Refactor 
11. TDD를 통해서 무엇을 이루려고 하는가? • TDD는 테스트 기술이 아니다 • TDD는 분석기술 + 설계 기술 • 군더더기 없고, 좋은 구조를 만들게 됨 • 군더더기? - Test 이외의 구현은 하지 않음 • 이런거 만들어 놓으면 쓰지 않을까? • 좋은 구조 • 명확한 책임의 분리, 관심사의 집중(SRP, OCP) 
12. 저는 개발할때 테스트를 하는데요
 그건 TDD가 아닌가요? 
13. 저는 개발할때 테스트를 하는데요
 그건 TDD가 아닌가요? • 설마 작성한 코드를 실행도 안하고 올리시지 않으시겠죠? • 테스트를 한다고 TDD는 아님 • Test 를 먼저 적고, 테스트에 맞춰서 구현하는
 테스트 주도적으로 개발하는 방식이 TDD 
14. TDD에서 쓰이는 테스트는 단위 테스트 
15. TDD에서 쓰이는 테스트는 단위 테스트 • 주의 사항 • 테스트는 • atomic 하게 • transactionable 하게 
16. TDD를 하면 이래서 좋습니다 
17. TDD를 하면 이래서 좋습니다 • (기획자는 없지만) 회의를 마무리 하면서 테스트 케이스를 적는다 • xx한 인풋으로 yy한 output이면 되죠? • 상호간의 이해를 회의실내에서 일치시키고 나온다 • 구현상 까리한 부분 • 테스트를 적는다 • 자연스럽게 엣지테스트가 만들어짐 
18. TDD를 하면 이래서 좋습니다 • 테스트를 통해 해야 할 일들이 가시화 됨 • 프로젝트가 예측 가능한 범위 내로 들어오기 시작함 • e.g. ‘이번 스프린트에는 x,y,z 를 할 수 있겠어!' 
19. 꿀팁 from BDD 
20. 꿀팁 from BDD • 갑자기 BDD? • Behavor Driven Development
 https://docs.cucumber.io/guides/bdd-tutorial/ • 비즈니스 로직 중심으로 테스트를 기술 
21. 꿀팁 from BDD • given, when, then
 • given • [상황,조건, 기초값] xx 가 주어진 상태에서, • when • [행동,액션] yy를 할 때, • then • [결과] zz가 된다. 
22. 꿀팁 from BDD • '잘' 기술해야함 • 잘못하면 산으로 감 • e.g. jpa 나 spring을 테스트하고 있을 수 있음 • 무슨 테스트를 적는지 명확하게 생각해야 함 
23. TDD 하고 싶어요. 어떻게 시작하죠? • 가겹게 책한권 읽으시죠
 테스트 주도 개발: By Example
 https://bit.ly/2UBMzYx
 • java 라면 junit • kotln 이라면 spek 이나 junit • javascript 라면 mocha, chai, jest • 다른 언어는 검색...  IUUQTHJUIVCDPNTVQFSGJTI[5*-USFFNBTUFSCPPLUEE@KBWB
    UEE
    ଼
    ٮۄࢲ
    ৘ઁܳ
    ॄࠌ਺
    LPUMJO
24. 테스트를 잘 적는 방법이 있는가? • 내가 만든 코드인데 테스트가 어렵다? • 잘못 만들었을 수도 있다.
 불필요한 의존성이 있을 수도 있음 • 모르겠는데 테스트를 짜기 어렵다 • 왜 짜기 어려운가? • 문제가 되는 부분을 분리할 수 없는가? • 여기부터 시작하면 됨 
25. 테스트를 잘 적는 방법이 있는가? • 테스트가 없는 레거시 코드와 효율적으로 싸우는 방법 
26. 테스트를 잘 적는 방법이 있는가? • 테스트가 없는 레거시 코드와 효율적으로 싸우는 방법 • 모름 (알면 같이 공유 해주세요) 
27. 테스트를 잘 적는 방법이 있는가? • 테스트가 없는 레거시 코드와 효율적으로 싸우는 방법 • 손대는 곳부터 천천히 싸우자
 테스트는 나부터 첫걸음 
28. 바빠서 테스트 할 시간이 없어요 • 코드는 만드는 순간부터 레거시고 비용이 발생한다 • 지금 테스트를 적지 않으면 미래의 내가 고생할 수 있다 • 어쩔 수 없이 선택의 문제 • 익숙해지면 조금 빨라짐 • 테스트하는 layer의 위치에 따라서 테스트에 발생하는 비용이 달라짐 • Domain 레이어 <<<< UI 레이어 
29. 잠깐 끼어드는 DDD 
30. 잠깐 끼어드는 DDD • Domain Driven Design • https://bit.ly/2zZ1qnf • 개발하려는 본질에 중점을 두어서... 
31. 잠깐 끼어드는 DDD • DDD 를 하다보면 레이어가 생김 • 각 레이어에 맞게(상황에 맞게) 테스트를 하면
 접근이 용이함! • 각자가 맡고있는 영역에 대해서만
 테스트 하면 됨! 
32. 테스트를 도와주는 친구들 • test double • stub • provide canned answers to calls made during the test • 결과론적으로 만들어진 상태를 검증 • mock • simulated objects that mimic the behavior of real objects in controlled ways • 행위 자체에 대한 검증 • spy • void 같이 return이 없는 메소드 내부의 행동을 감시 • before, after • 테스트가 시작하기전에 초기 daa를 넣거나
 테스트 후 리소스 정리등에 사용 
33. 정량지표 coverage • 뜻, 테스트코드가 지나간 자리 • coverag 100%가 좋은걸까? • coverage는 억지로라도 올릴 수 있음 • 다만 테스트가 지나간 자리가 완벽하다고(프로그래머의 의도대로 동 작한다고) 보장할 수 없음 • 테스트를 의미있게 작성해야함 
34. TDD는 언제나 옳은가? • 라이브러리나, 언어에 익숙해지기 부터 • TDD가 항상 옳지 않을 수 있음 
35. 근데, TDD가 죽었데요 • 근데 TDD가 죽었데요 • DHH - https://dhh.dk//2014/tdd-is-dead-long-live-testing.html • DHH , Kent Beck 의 'Is TDD dead?' feat 마틴파울러 - https://plus.google.com/events/ci2g23mk0lh9too9bgbp3rbut0k • TDD 3부작 - http://www.moreagile.net/2014/05/IsTDDdead1.html • 논점 • TDD의 오버헤드 • 솔직히 테스트 적는데 시간이 드는건 인정해야함 • TDD가 설계를 망친다 • 좋은 설계는 어디로 가고, 테스트 하기 쉬운 설계를 짜고 있음 • TDD가 테스트를 망친다 • 테스트를 위한 테스트를 하는 주화입마 상태에 빠지게 됨 
36. Conclusion 
37. Conclusion • TDD 하세요.두번하세요. • Red -> Green -> Blu • Fail -> Succes -> Refctor • 그리고 이 Test들을 꼭 CI 에 넣어주세요 
38. Conclusion • TDD 하세요.두번하세요. • Red -> Green -> Blu • Fail -> Succes -> Refctor • 그리고 이 Test들을 꼭 CI 에 넣어주세요 • 그래야 문화가 전파되고, 같이 작업하는 사람이 실수하더라도 알 수 있음 
39. 그 외 읽어볼만한 것 • 절판된 TDD 실천법과 도구가 pdf 로 풀렸음! • https://repo.yona.io/doortts/blog/issue/1 •