사내 TDD 도입 설명 문서 하지만 TDD를 모두 귀찮아 하였다...ㅠㅠ

1. TDD (Test Driven Development)
C3팀 도입 설명 문서
2016.07.14
S/W개발 C3팀 김경송

2. Contents
Page 2
1. TDD 란?
2. TDD 를 왜 써야 하나?
3. TDD 도입 시 장점
4. TDD 도입 시 단점
5. 그래서 우리는 뭘 하면 되나요?
6. 여담

3. 1. TDD 란?
Page 3
TDD라는 거 처음 들어 보셨 나요?
몰라서 못하는 걸까요?
알지만 못하는 걸까요?
할 수 있지만 하지 않는 걸까요?
하기 싫은 걸까요?

4. 1. TDD 란?
Test-Driven Development
해석하면 -> 테스트 주도 개발
설계 코드 작성 테스트(수동)현재 :
설계언제? :
Test 코드
작성
Page 4
코드 작성
설계 수정
설계 수정

5. 2. TDD 를 왜 써야 하나?
Page 5
낮엔 수정한 코드 잘
동작할까?
새벽에 live 패치 한다고
했는데 문제 생기면 어쩌지?
내가 테스트 할 때는
괜찮았는데…..
근데 내가 고친 부분이 다른
부분에 영향을 주지는
않을까?
더 테스트 해볼 껄 그랬나…
장애… 안 나겠지…?
<상황>
1. 오늘 낮에 중요한 기능 수정 후 릴리즈
2. 해당 릴리즈 된 버전으로 live 패치 예정
3. 근데 그게 오늘 새벽에 패치 됨
4. 개발 후 추가 검증 절차 없었음
5. 집에서 잠들기 전

6. 2. TDD 를 왜 써야 하나?
Page 6
우리는 왜 항상 버전 릴리즈 후 불안에 떨어야 하는가?
우리는 왜 버전 릴리즈 때마다 똑같은 기능 테스트 / 단위
테스트를 반복적으로 수동으로 해야만 하는가…
우리는 왜 테스트가 지겹고 시간이 오래 걸리는가…
우리는 왜 릴리즈 전 테스트에 이렇게 시간과 노력을
들이고도 X욕을 먹어야만 하는가…
TDD 를 도입하면 위의 문제를 모두 해결 할 수 있는가?

7. 2. TDD 를 왜 써야 하나?
Page 7
예상되는 반응들…
난 TDD 없이도 여태 개발 잘 했는데요?
난 테스트 코드 만들고 하는데 더 시간이 걸리고 귀찮을
거 같은 데요?
난 지금 매우 바쁜데요. 프로젝트 일정 맞추기도 힘들어
죽겠는데, 테스트 코드부터 만들어야 한다 구요? 시간이
남아 도시나 봐요?
난 뭔가 새로 배우고 쓰고 하는 거 힘들어요. 살던 대로
살고 싶어요.

8. 2. TDD 를 왜 써야 하나?
Page 8
예상되는 반응들…
난 TDD 없이도 여태 개발 잘 했는데요?
-> 흠… 적어도 우리팀(C3팀)에서는… 하아…
난 테스트 코드 만들고 하는데 더 시간이 걸리고 귀찮을
거 같은 데요?
-> 장애 나서 불려가는게 더 귀찮지 않을까요?
난 지금 매우 바쁜데요. 프로젝트 일정 맞추기도 힘들어
죽겠는데, 테스트 코드부터 만들어야 한다 구요? 시간이
남아 도시나 봐요?
-> 조금만 멀리 보면 더 시간이 단축 될 수 있어요!
난 뭔가 새로 배우고 쓰고 하는 거 힘들어요. 살던 대로
살고 싶어요.
-> 죄….죄송.. ㅠㅠ

9. 2. TDD 를 왜 써야 하나?
Page 9
개발이 하고 싶어?
객관적으로 난 개발자
로서의 실력은 어느
정도일까?
다른 회사나 다른 나라의
개발자들과 잘 협업할 수
있을까?
개발을 위한 연습이나
공부는 언제/어떻게
해야하는 걸까?

10. 2. TDD 를 왜 써야 하나?
Page 10
개 인
회 사
- 좋은 개발자 / 엔지니어가 되고 싶다
- 좋은 소프트웨어를 만들고 싶다
- 좋은 개발자를 양성하고 싶다
- 좋은 개발자들이 좋은 소프트웨어를 만들어줬으면
좋겠다
- 장애 나는 소리 좀 안 나게 해라

11. 2. TDD 를 왜 써야 하나?
Page 11
개 인
회 사
- 좋은 개발자 / 엔지니어가 되고 싶다
- 좋은 소프트웨어를 만들고 싶다
- 좋은 개발자를 양성하고 싶다
- 좋은 개발자들이 좋은 소프트웨어를 만들어줬으면
좋겠다
- 장애 나는 소리 좀 안 나게 해라

12. 3. TDD 도입 시 장점
Page 12
 좀 더 객체 지향적인 코드 생산 가능
: TDD 자체가 코드의 재사용성을 보장해야만 가능
: 테스트 코드가 없을 때에는 한 Class나 Method에 이런저런 기능들을 막
때려 박는데 제한이 없다
: 솔직해지자. 우리는 코드의 재 사용에 대해 개념이 없다.
 재설계 시간 단축
: 내가 뭘 만드는지에 대해 분명한 정의를 세우고 코딩을 하게 된다.
: 내가 뭘 만들려고 했었더라? 괜히 주석만 자꾸 늘어난다. //나중에 확인 필요…
: 솔직해지자. 우리는 개발하기전 인터페이스, 클래스구조 등에 대해서
우린 생각하지 않는다.
 디버깅 시간 단축
: 기존 방식에서는 에러가 발생 했을 때 Network Layer인지 Service Layer인지
DB Layer인지 찾기가 힘들다
: 단순 버그인지 설계 문제인지 추적 조차 결국 소스 리뷰를 해야만 알 수 있다.
 테스트 문서의 대체 나 작성에 도움
 추가 구현 / 유지 보수 / Refactoring 에 매우 유연
: 추가 기능에 대한 요구사항. 새로운 기술의 도입. 우리는 바뀌는 것들에
대한 테스트할 생각에 시도조차 못하고 포기한다. (그거 누가 테스트 하나요?)

13. 4. TDD 도입 시 단점
Page 13
 솔직히 아주 쉽지는 않습니다
 설계나 디자인에 대한 지식이 없다면 더 힘들 수 도…
 이미 잘못 디자인된 소스코드의 테스트 코드는
마찬가지로 엉망이 됩니다. (Refactoring 필요)
 TDD 자체가 일이 될 수 있습니다.
 어쩌면 객체 지향 개발에 대한 공부부터 해야할 수도
있습니다. 하지만 이것은 단점이 라기 보다는 올바른
방향을 이제야 찾은 것입니다.

14. 5. 그래서 우리는 뭘 하면 되나요?
Page 14
TDD에 대한 기본 적인 공부를 하세요. 책도 읽으세요.
기존 만들어진 Java Server들에 테스트 코드를 작성해
보세요. (쉬운 것 부터 시작합시다)
사용하기 편한 plugin 들을 찾아 봅시다. (JunitMax 라던
가 Infinitest등)
새로운 기능 추가시 테스트 코드부터 작성해 봅시다. 뭐가
달라 보이는지 느껴봅시다.
결국 우리는 통합 테스트 툴이나 지속적인 통합 환경(CI)
까지 고려를 하게 될 것 입니다.

15. 6. 여담
Page 15
TDD 도입으로 얻는 이득
- 있을 수도, 없을 수도 있습니다
- 분명한 것은 여러분들의 객체지향 개발의 새로운 시선을
느낄 수 있다는 것은 분명합니다
- 개발자로써 한단계 더 나아갈 수 있는 계기가 될 수 있을
것을 기대합니다.
Spring 창시자 : 로드 존슨(Rod Johnson)
“성공하는 테스트만 만들지 말자.
항상 네거티브 테스트를 먼저 만들라”
“테스트 기반 개발 방식이 없었더라면,
Spring은 세상에 나오지 못할 수도 있었다”

16. 6. 여담
Page 16
처음부터 완벽한 테스트 코드에 욕심 부릴 필요 없습니다!
기존에 안하던 것을 하는게 아닙니다. 기존에는 내 손으로
하나하나 바이너리 바꾸고 서버 띄우고 수동으로 테스트
하던 행위 중 일부를 코드로 바꾸는 것 뿐입니다!
산출물이 아닙니다! 부담 가지지 마세요! TDD자체가
목적이 아닙니다. 우리의 목적은 릴리즈 후 발 뻗고 꿀 잠을
잘 수 있냐 없냐 입니다!
테스트코드 만들었다고 월급 안올려줍니다! 그냥 우리들이
편하려고 하는 겁니다!