Violentica Path SystemMaking History with TDD

Violentica Path System

• RV 581 을 시작으로 현재진행형으로 추가된 모듈

• VGM::GLOBAL 에 포함

목적• VWT(Violentica World Tool) 의 문제 –현재 working directory 의 1 차 상위 폴더에

있는 파일까지만 불러올 수 있다 .–그 이상 떨어진 파일은 불러오지 못함 .

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

TDD?

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

TDD 를 하는 장점• 두뇌의 체력소모가 적다• 단위테스트를 미리 거쳐 , 검증된 모듈을 만들

수 있으므로 디버깅 시 깊은 곳 까지 들어가지 않는다 ( 신뢰성 있는 모듈 )–= 엄청나게 힘든 디버깅이 잘 없다

• 결과적으로 개발 속도는 올라간다

TDD 를 하는 단점• 귀찮다• 신뢰성을 위해 너무 작은 곳 까지 직접

테스트를 하면서 넘어가야 한다• 버릇 들이기 힘들다

TDD 개발1. 모든 경우의 수를 상정해 놓음 ( 단위테스트 생성 )2. 구현 사이클

1. 사이클1. 하드코딩2. 테스트3. TODO 확립

2. 리팩토링1. 리팩토링은 사이클 중간중간에 끼어서 한다 .

3. 2 를 1 에서 설정한 모든 경우의 수에 대해 사이클링

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

TDD1 : 함수 제작

TDD2 : 1 차 사이클1. 하드코딩

• 일부분이 같은 패스일 때– C:\_PROJECTS\VGM\vwt\ViolenticaWorld-

Tool7\images\aag.dds– C:\_PROJECTS\VGM\trunk\VGM

• 당장의 코드는 다음과 같다

TDD2 : 1 차 사이클2. 테스트

• 테스트 (= 실행 ) 성공 !• 뭘 해야될지 모르겠다 .–우선 오른쪽에 variable 을 다 써본다 .

TDD2 : 1 차 사이클3. TODO 확립

• 닥치고 진행

이 라인 밑으로는 의미가 전혀 없는 코드다 . 어디서 멈출지 이 정도는 센스껏 한다 .

TDD2 : 2 차 사이클1. 하드코딩

• 얻으려는게 뭐지 ?–심플하게 해결한다 . 무식할 필요가 있음–디버거를 멈추고 코딩 한다는 의식을 버린다 .

TDD2 : 2 차 사이클2. 테스트

• 그래서 , 잘 돌아가나 ?–오오 좋아 !

TDD2 : 2 차 사이클3. TODO 확립

• 분리하자

TDD2 : 3 차 사이클1. 하드코딩

• 분리한다

TDD2 : 3 차 사이클2. 테스트

• 물론 통과 이상무 !• 이렇게까지 자세히 테스트 하는 이유는 솔까 std::tstring 에 대한 + 연산자가

오작동하거나 아무튼 스텝이 많이 들어갔기 때문• 그대의 두뇌를 믿지 말라 . 뇌에게 속는다 . 프로그래머는 코딩으로 말함 .

TDD2 : 3 차 사이클3. TODO 확립

• 여기서 뭘 하지 ?–당연히 앞 , 뒤를 변수로 빼고–그 변수를 생성하는 코드를 만든다 .

앞뒤

TDD2 : 4 차 사이클1. 하드코딩

• 앞 / 뒤를 변수로 뺌– front_end / last_end

• last_end 를 컴퓨터가 만들게 함 .• front_end 는 일단 냅두자 . 머리를 혹사시키면 안됨

TDD2 : 4 차 사이클2. 테스트

• last_end 와 pathOut 에 모두 정상값이 들어오는 걸 확인함 . 정상 작동하네 ?!

그때그때 추가되는 변수는 바로 watch 에 추가하는 센스

TDD2 : 4 차 사이클3. TODO 확립

• last_end 를 만들었으면 ?– front_end 도 만들어야지 !

TDD2 : 5 차 사이클1. 하드코딩

• front_end 만들었다…

TDD 라고 고찰을 안 하는 것은 아니다 .단지 짧게짧게 하기 때문에 실수가 적을 뿐

TDD2 : 5 차 사이클2. 테스트

front_end / last_end 값이여전히 변화가 없다 . 성공

TDD2 : 6 차 사이클1. 하드코딩

• literal 3 에 의미부여 (= 변수화 )

TDD2 : 6 차 사이클2. 테스트

• 물론 테스트 통과– number_same = 3

새로 변수 나오면 watch 에 올리는 건 당연한 센스

TDD2 : 6 차 사이클3. TODO 확립

• literal 로 되어 있는 숫자를 변수화 !

• 이번 TODO 는 약간 refactoring 단계의 성향을 함께 띔 .

위의 3 은 바꿨다 .아래 2 를 바꿔보자 !!!

TDD2 : 7 차 사이클1. 하드코딩

• 2 를 number_uppermove 로 변환

생각하지말고 주석에 써진대로 그냥 구현한다 .왜냐고 ? 지금 생각하면 아까 생각한게 아깝잖아 .두뇌용량의 낭비 = 금방피로해짐

바로 아까의 2 자리를 대체

TDD2 : 7 차 사이클2. 테스트

• number_uppermove = 2 테스트통과

물론 최종 output 은 항상 체크하고 있겠지 ?

TDD : 7 차 사이클3. TODO 확립

• 첫 번째 경우의 수 (= 단위 테스트 ) 에 대해–통과했음 . 두 번째 큰사이클을 돌아야 함 .

• 두 번째는 일단 첫 번째 경우와 같은 함수이므로 , 실행부터 해본다 .

TDD : 7 차 사이클리팩토링 : TODO

1. front_end 가 last_end 보다 먼저 위치하는게 보기 좋음 .

2. 쓰면서 만든 주석정리3. 구조화를 위해 front_end 와 last_end 를

std::tstring 대신 GLOBAL::PATH 객체로 바꾸고 , 마지막에 pathOut 을 제작할 때에만 std::tstring 형태로 변환(GLOBAL::CollapsePath 이용 )

TDD : 7 차 사이클리팩토링 : 코딩

• 아까 작성한 TODO 중 1, 2 번은 금방해결

1 : 순서 바꿈

2 : 주석은 지움

TDD : 7 차 사이클리팩토링 : 코딩

• 3 번 항목을 어떻게 하지 ?–목표를 떠올리자 : std::tstring -> PATH –걍 닥치고 치환

TDD : 7 차 사이클리팩토링 : 코딩

• 닥치고 치환하면 에러는 누가잡나 ?–컴파일러가

TDD : 7 차 사이클리팩토링 : 코딩

• 컴파일 에러만 잡았다 .

TDD : 7 차 사이클리팩토링 : 테스트

• 보다시피 정상작동하고 pathOut 도 OK–컴파일에러보다 복잡한 에러가 있으면 사이클을

돈다 .

TDD3 : 두 번째 조건 체크• 나보다 상위의 패스일 때– C:\_PROJECTS\VGM– C:\_PROJECTS\VGM\trunk\VGM ( 현재패스 )

• 목표는 ?– C:\_PROJECTS\VGM 를• ..\..\ 로

• 다시 2 로 돌아가서 사이클

TDD2 : 1 차 사이클테스트

• 뭘 해야되 ? 일단 돌려본다 : • 아무것도 안했는데 테스트를 통과했다 .–테스트를 통과했으므로 건드리지 않고 간다 .

TDD 에서는 ‘땡’잡는 경우가 자주 있다 .

TDD3 : 세 번째 조건 체크• 나보다 하위의 패스일 때– C:\_PROJECTS\VGM\trunk\VGM\Debug\VG-

M.obj– C:\_PROJECTS\VGM\trunk\VGM ( 현재패스 )

• 목표는 ?– C:\_PROJECTS\VGM\trunk\VGM\Debug\VG-

M.obj– 를

• Debug\VGM.obj 로• 다시 2 로 돌아가서 사이클

TDD2 : 1 차 사이클테스트

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

TDD3 : 네 번째 조건 체크• 나의 패스와 시작부터 다를 때– D:\\000\\MP3\\kfc.mp3– C:\_PROJECTS\VGM\trunk\VGM ( 현재패스 )

• 목표는 ?–그냥 절대경로로 바로 돌려주면 될 것 같다 .–왠지 테스트도 그냥 통과할 것 같다 .

• 다시 2 로 돌아가서 사이클

TDD2 : 1 차 사이클테스트

• 왠지 테스트는 그냥 통과할 것 같았다 .• 현실 : 뭔가 맞긴 한 것 같은데… ?–모든 경로가 안 맞으면 우주까지 거스를 기세

문제는 없어 보이지만 지저분하다…보통 이런 경로를 원하지 않을 것이다 .

TDD2 : 1 차 사이클TODO 확립

• 하나도 안 맞으면 거슬러올라가는 것 없이 주어진 경로를 그대로 리턴하도록 함–지금 경로에서 루트보다 더 위로 거슬러올라가야

한다는 말의 의미 = 상대경로로 표시가 불가능하다는 말이므로 그냥 그대로 돌려줌

TDD2 : 2 차 사이클하드코딩

• 간단한 예외처리

TDD2 : 2 차 사이클테스트

• 정확히 나오는 것을 확인– 코딩 스타일따라 다른데 , 가능한 최소 변경함 .

• 기존 단위 테스트를 모두 다시 하지 않기 위함

TDD3 : 마지막 조건 체크• 상대경로일 때– Debug\VGM.obj– C:\_PROJECTS\VGM\trunk\VGM ( 현재패스 )

• 목표는 ?–그냥 리턴한다 .• 여기까지 TDD 를 진행했다면 , 과정에 따라 습득한

지식에 의해 자동으로 이미 상대경로가 들어왔을때의 상대경로 변환은 무의미하다고 알게됨

• 하지만 테스트는 중요하다 .

• 다시 2 로 돌아가서 사이클

TDD2 : 1 차 사이클테스트

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

결론• 단단한 구조• 마구잡이로 들이대면서 코딩할 때 저렇게 모든

테스트케이스를 한번에 통과하는 단단한 구조를 만들 수 있는가 ?

• TDD 는 대단한게 아니다–아주 살짝만 바꿔나가는 부분임

Let’s TDD

• Test Driven Development–소프트웨어 개발 뿐 아니라 일반적인데도 적용이

가능 .