1. Violentica Path System
Making History with TDD

2. Violentica Path System
• RV 581을 시작으로 현재진행형으로 추가
된 모듈
• VGM::GLOBAL 에 포함

3. 목적
• VWT(Violentica World Tool)의 문제
– 현재 working directory 의 1차 상위 폴더에 있
는 파일까지만 불러올 수 있다.
– 그 이상 떨어진 파일은 불러오지 못함.

4. 솔루션
• 다음의 함수를 추가.

5. TDD?
• 개념 설명은 다음에서
– http://google.com

6. TDD를 하는 장점
• 두뇌의 체력소모가 적다
• 단위테스트를 미리 거쳐, 검증된 모듈을 만
들 수 있으므로 디버깅 시 깊은 곳 까지 들
어가지 않는다(신뢰성 있는 모듈)
– =엄청나게 힘든 디버깅이 잘 없다
• 결과적으로 개발 속도는 올라간다

7. TDD를 하는 단점
• 귀찮다
• 신뢰성을 위해 너무 작은 곳 까지 직접 테스
트를 하면서 넘어가야 한다
• 버릇 들이기 힘들다

8. TDD 개발
1. 모든 경우의 수를 상정해 놓음(단위테스트 생
성)
2. 구현 사이클
1. 사이클
1. 하드코딩
2. 테스트
3. TODO확립
2. 리팩토링
1. 리팩토링은 사이클 중간중간에 끼어서 한다.
3. 2를 1에서 설정한 모든 경우의 수에 대해 사
이클링

9. TDD1 : 단위 테스트 제작
• 5가지 경우의 수를 생각해놓음
• 현재의 working path =
– C:_PROJECTSVGMtrunkVGM

10. TDD1 : 함수 제작

11. TDD2 : 1차 사이클
1. 하드코딩
• 일부분이 같은 패스일 때
– C:_PROJECTSVGMvwtViolenticaWorldToo
l7imagesaag.dds
– C:_PROJECTSVGMtrunkVGM
• 당장의 코드는 다음과 같다

12. TDD2 : 1차 사이클
2. 테스트
• 테스트(=실행) 성공!
• 뭘 해야될지 모르겠다.
– 우선 오른쪽에 variable을 다 써본다.

13. TDD2 : 1차 사이클
3. TODO 확립
• 닥치고 진행
이 라인 밑으로는 의미가 전혀 없는 코드다.
어디서 멈출지 이 정도는 센스껏 한다.

14. TDD2 : 2차 사이클
1. 하드코딩
• 얻으려는게 뭐지?
– 심플하게 해결한다. 무식할 필요가 있음
– 디버거를 멈추고 코딩 한다는 의식을 버린다.

15. TDD2 : 2차 사이클
2. 테스트
• 그래서, 잘 돌아가나?
– 오오 좋아!

16. TDD2 : 2차 사이클
3. TODO 확립
• 분리하자

17. TDD2 : 3차 사이클
1. 하드코딩
• 분리한다

18. TDD2 : 3차 사이클
2. 테스트
• 물론 통과 이상무!
• 이렇게까지 자세히 테스트 하는 이유는 솔까 std::tstring 에 대한 + 연산자가
오작동하거나 아무튼 스텝이 많이 들어갔기 때문
• 그대의 두뇌를 믿지 말라. 뇌에게 속는다. 프로그래머는 코딩으로 말함.

19. TDD2 : 3차 사이클
3. TODO 확립
• 여기서 뭘 하지?
– 당연히 앞, 뒤를 변수로 빼고
– 그 변수를 생성하는 코드를 만든다.
앞
뒤

20. TDD2 : 4차 사이클
1. 하드코딩
• 앞/뒤를 변수로 뺌
– front_end / last_end
• last_end를 컴퓨터가 만들게 함.
• front_end 는 일단 냅두자. 머리를 혹사시키면 안됨

21. TDD2 : 4차 사이클
2. 테스트
• last_end와 pathOut에 모두 정상값이 들어
오는 걸 확인함. 정상 작동하네?!
그때그때 추가되는 변수는
바로 watch에 추가하는 센스

22. TDD2 : 4차 사이클
3. TODO 확립
• last_end를 만들었으면?
– front_end도 만들어야지!

23. TDD2 : 5차 사이클
1. 하드코딩
• front_end 만들었다…
TDD라고 고찰을 안 하는 것은 아니다.
단지 짧게짧게 하기 때문에 실수가 적을 뿐

24. TDD2 : 5차 사이클
2. 테스트
front_end / last_end값이
여전히 변화가 없다. 성공

25. TDD2 : 6차 사이클
1. 하드코딩
• literal 3에 의미부여(=변수화)

26. TDD2 : 6차 사이클
2. 테스트
• 물론 테스트 통과
– number_same = 3
새로 변수 나오면 watch에
올리는 건 당연한 센스

27. TDD2 : 6차 사이클
3. TODO 확립
• literal 로 되어 있는 숫자를 변수화!
위의 3은 바꿨다.
아래2를 바꿔보자!!!
• 이번 TODO는 약간 refactoring 단계의 성향
을 함께 띔.

28. TDD2 : 7차 사이클
1. 하드코딩
• 2를 number_uppermove로 변환
생각하지말고 주석에 써진대로 그냥 구현한다.
왜냐고? 지금 생각하면 아까 생각한게 아깝잖아.
두뇌용량의 낭비 = 금방피로해짐
바로 아까의 2 자리를 대체

29. TDD2 : 7차 사이클
2. 테스트
• number_uppermove = 2 테스트통과
물론 최종 output은 항상 체크하고 있겠지?

30. TDD : 7차 사이클
3. TODO 확립
• 첫 번째 경우의 수 (=단위 테스트) 에 대해
– 통과했음. 두 번째 큰사이클을 돌아야 함.
• 두 번째는 일단 첫 번째 경우와 같은 함수이
므로, 실행부터 해본다.

31. TDD : 7차 사이클
리팩토링 : TODO
1. front_end 가 last_end보다 먼저 위치하는
게 보기 좋음.
2. 쓰면서 만든 주석정리
3. 구조화를 위해 front_end와 last_end를
std::tstring 대신 GLOBAL::PATH 객체로
바꾸고, 마지막에 pathOut을 제작할 때에
만 std::tstring 형태로 변환
(GLOBAL::CollapsePath 이용)

32. TDD : 7차 사이클
리팩토링 : 코딩
• 아까 작성한 TODO 중 1, 2번은 금방해결
1 : 순서 바꿈
2 : 주석은 지움

33. TDD : 7차 사이클
리팩토링 : 코딩
• 3번 항목을 어떻게 하지?
– 목표를 떠올리자 : std::tstring -> PATH
– 걍 닥치고 치환

34. TDD : 7차 사이클
리팩토링 : 코딩
• 닥치고 치환하면 에러는 누가잡나?
– 컴파일러가

35. TDD : 7차 사이클
리팩토링 : 코딩
• 컴파일 에러만 잡았다.

36. TDD : 7차 사이클
리팩토링 : 테스트
• 보다시피 정상작동하고 pathOut도 OK
– 컴파일에러보다 복잡한 에러가 있으면 사이클
을 돈다.

37. TDD3 : 두 번째 조건 체크
• 나보다 상위의 패스일 때
– C:_PROJECTSVGM
– C:_PROJECTSVGMtrunkVGM (현재패스)
• 목표는?
– C:_PROJECTSVGM 를
• .... 로
• 다시 2로 돌아가서 사이클

38. TDD2 : 1차 사이클
테스트
• 뭘 해야되? 일단 돌려본다 :
• 아무것도 안했는데 테스트를 통과했다.
– 테스트를 통과했으므로 건드리지 않고 간다.
TDD에서는 ‘땡’잡는
경우가 자주 있다.

39. TDD3 : 세 번째 조건 체크
• 나보다 하위의 패스일 때
– C:_PROJECTSVGMtrunkVGMDebugVGM.ob
j
– C:_PROJECTSVGMtrunkVGM (현재패스)
• 목표는?
– C:_PROJECTSVGMtrunkVGMDebugVGM.ob
j
– 를
• DebugVGM.obj 로
• 다시 2로 돌아가서 사이클

40. TDD2 : 1차 사이클
테스트
• 말 안 해도 안다. 일단 돌려본다 :
• 아무것도 안 했는데 테스트를 통과했다.
– 어디선가 이 장면을 본 것 같다!

41. TDD3 : 네 번째 조건 체크
• 나의 패스와 시작부터 다를 때
– D:000MP3kfc.mp3
– C:_PROJECTSVGMtrunkVGM (현재패스)
• 목표는?
– 그냥 절대경로로 바로 돌려주면 될 것 같다.
– 왠지 테스트도 그냥 통과할 것 같다.
• 다시 2로 돌아가서 사이클

42. TDD2 : 1차 사이클
테스트
• 왠지 테스트는 그냥 통과할 것 같았다.
• 현실: 뭔가 맞긴 한 것 같은데…?
– 모든 경로가 안 맞으면 우주까지 거스를 기세
문제는 없어 보이지
만 지저분하다…
보통 이런 경로를 원
하지 않을 것이다.

43. TDD2 : 1차 사이클
TODO 확립
• 하나도 안 맞으면 거슬러올라가는 것 없이
주어진 경로를 그대로 리턴하도록 함
– 지금 경로에서 루트보다 더 위로 거슬러올라가
야 한다는 말의 의미 = 상대경로로 표시가 불가
능하다는 말이므로 그냥 그대로 돌려줌

44. TDD2 : 2차 사이클
하드코딩
• 간단한 예외처리

45. TDD2 : 2차 사이클
테스트
• 정확히 나오는 것을 확인
– 코딩 스타일따라 다른데, 가능한 최소 변경함.
• 기존 단위 테스트를 모두 다시 하지 않기 위함

46. TDD3 : 마지막 조건 체크
• 상대경로일 때
– DebugVGM.obj
– C:_PROJECTSVGMtrunkVGM (현재패스)
• 목표는?
– 그냥 리턴한다.
• 여기까지 TDD를 진행했다면, 과정에 따라 습득한
지식에 의해 자동으로 이미 상대경로가 들어왔을때
의 상대경로 변환은 무의미하다고 알게됨
• 하지만 테스트는 중요하다.
• 다시 2로 돌아가서 사이클

47. TDD2 : 1차 사이클
테스트
• 간단한 테스트 정도로 종료 : 정확함
– 이미 머릿속에서부터 테스트가 완료 되 있음

48. 결론
• 단단한 구조
• 마구잡이로 들이대면서 코딩할 때 저렇게
모든 테스트케이스를 한번에 통과하는 단
단한 구조를 만들 수 있는가?
• TDD는 대단한게 아니다
– 아주 살짝만 바꿔나가는 부분임

49. Let’s TDD
• Test Driven Development
– 소프트웨어 개발 뿐 아니라 일반적인데도 적용
이 가능.