왕초보의 TDD 실전, 이렇게 해보자!
Posted by 시리니07月 10
지난 번 포스트에 이어서 이번에도 TDD (Test Driven Development) 가 주제입니다. 사실 쓸 거리는 많은데 아무래도 가장 많은 시간을 들여 공부하고 또 적용하고 있다보니 테스트 주도 개발 이야기를 하지 않을 수가 없네요. ^^; 주제가 재미 없을 수도 있겠지만, TDD 에 관심이 많으신 분들과 우연히라도 한 번 이야기를 나눠 볼 기회가 있지 않을까 하여 또 주제 넘게 글을 써 봅니다.
계속 된 TDD 실무 적용 연습을 통해서 한 가지 깨달은 게 있습니다. 먼저 이 부분을 명확히 해야 할 것 같더라구요. TDD 는 개발자의 내공이 일정 수준 이상 되어야 한다는 걸 몸소 깨닫게 되었습니다. 일정 수준이 어느 정도인지는 사람 마다 다른 것 같지만, 제가 느끼기에는 기존의 UML 등을 이용한 설계 능력도 어느 정도 뒷받침 되고 소프트웨어 개발 프로세스에 대한 전반적인 시야도 있으며, 결정적으로 기존 개발 프로세스에 불만을 느낄 수 있는 정도의 실력이 있어야 합니다.
저는 그런 의미에서 TDD 를 자유롭게 쓸 만한 내공이 부족했습니다. 실무에 적용하면서 중간에 몇 번씩 기존 개발 방식으로 돌아가고 싶다는 유혹을 느꼈고, TDD 의 장점을 머리로만 이해했지 가슴으로 이해하진 못했기 때문입니다.
하지만, 이왕 시작한 거 끝을 봐야 겠다는 각오도 있었고, 지도 선배님의 드라이브도 강력했기 때문에 계속해서 멘토링을 받으면서 개발을 진행해 나갔습니다. 그러면서 약간 눈높이를 맞춰서 저에게 맞는 방식으로 접근법을 좀 더 체계화 해 보았는데요, 아래와 같은 방법입니다.
1. 먼저 프로그램 개발 전에 Use Case 를 PPT 로 작성 (UI 를 중심으로)
2. 작성된 PPT 를 바탕으로 사용자 시나리오를 다시 Word 로 작성 (행동 하나 하나를 분리)
3. Word 로 작성된 시나리오를 보고 사용할 디자인 패턴에 맞게 설계 (MVC, MVVM, ...)
4. 대략적인 UML 설계도와 Word 문서에 쓰인 시나리오를 참고하여 프로젝트 생성
5. 유닛 테스트 (예: gtest, ...) 적용
6. Word 로 작성된 시나리오를 보고 주석으로 테스트 코드 작성
7. 작성된 주석들을 보고 실제 테스트 코드 작성
8. 테스트 코드는 단계별 (예: V → C → M) 로 작성할 것
9. 테스트 실행 및 테스트 코드를 보면서 껍데기 목업 클래스 / 빈 메소드 구현
10. 전체 구조를 먼저 검토 후 다시 세부 구현들을 실제로 하나씩 구현하며 테스트
위의 순서에서 특히 저에게 와 닿은 것은 처음 1번과 2번 단계입니다. 저는 시각적으로 먼저 이미지화 해서 어떤 상황이나 구조를 이해하는 습관이 있는데, 정말 저에게 필요한 단계였습니다. 아무리 단순한 프로그램이라 하더라도 UI 를 그려보고 직접 사용자가 되어서 한 번 가상으로 테스트를 해 보는 겁니다. 그리고 이 걸 바탕으로 다시 Word 로 한 줄 한 줄 표현해보니 마치 그림 그릴 때 밑 그림을 그리는 것 처럼 상상이 훨씬 구체적으로 잘 되었습니다.
디자인 패턴을 선택하고 적용하면서 시나리오에 작성된 기능들을 대략적으로 구분하는 작업은 지도 선배님과 함께 진행하였는데요, 사실 위의 작업들 상당수를 함께 작업 하면서 궁금한 점은 바로 질문하고 쌍방 검토를 진행해 보았습니다. 특히 테스트 코드를 주석을 보면서 직접 작성할 땐 짝 프로그래밍을 도입해서 제가 코드를 작성하고 지도 선배님이 대략적인 방향을 알려주는 역할을 해 주셨는데요, 프로그래밍 노하우를 직접 전수 받는 느낌이었습니다! 굉장합니다!
제가 먼저 제 생각과 의도를 말하고, 이를 코드로 구현하면 지도 선배님이 이를 다시 검토하고 피드백을 줍니다. 그리고 다시 코드를 바꿔보고 제안 받은 것들에 대해 반영해 보면서 코드를 다듬습니다. 이렇게 다듬어진 코드는 제가 미쳐 생각하지도 못한 많은 문제들을 미리 발견 할 수 있도록 해주며 코드를 작성하는 노하우를 배울 수 있게 해줍니다. 마치 비기를 전수 받는 느낌이랄까요, 사부와 1대 1로 무공 연마를 하는 그런 느낌이었습니다.
좀 더 세부적인 단계를 나눠서 다시 TDD 를 접하고, 이 과정에서 지도 선배님과 상시로 피드백을 주고 받으면서 프로그램을 테스트 하면서 동시에 저 스스로의 지식과 노하우를 끝 없이 점검합니다. 분명히, 개발 속도는 아직까지도 굉장히 느리고 또 선배 개발자분의 노고가 필요한 일임에는 틀림 없지만 배우고 실행하는 저에겐 더 할 나위 없는 배움의 장이요, 내공을 단단히 쌓아 갈 수 있는 절호의 기회라 할 수 있겠습니다.
TDD 는 제가 생각 했을 때, 빨리 실패하고 빨리 수정하면서 개발 싸이클을 빠르게 가져가는 게 무엇 보다도 장점인 것 같습니다. 빨리 실패하기 위해서는 구현 전에 반드시 먼저 테스트를 해야 하고, 테스트를 잘 하기 위해서는 무엇 보다도 사용 시나리오를 제대로 확립하고 디자인 패턴에 따른 설계도 잘 해야 할 것입니다.
빨리 수정하기 위해서는 혼자서는 안됩니다. 내 코드를 다른 개발자가 보고 피드백을 줄 수 있어야만 합니다. 이왕이면 나 보다 더 뛰어난 선배 개발자님과 함께 할 수 있다면 좋겠지요. 첨삭 지도를 받지 못하더라도, 최소한 어떤 부분을 더 신경 써야 할지에 대해선 알 수 있을 겁니다.
TDD, 개념도 어렵지만 실천은 정말 더 어려운 것 같습니다. 혼자서 했다간 도중 하차하기 쉽상일 듯 합니다. 반드시 함께 할 사람이 있어야 할 것 같습니다. 아직 왕초보이지만, 계속 해 나가면서 배우고 또 깨닳은 것들은 부족한대로 공유하겠습니다. :)
계속 된 TDD 실무 적용 연습을 통해서 한 가지 깨달은 게 있습니다. 먼저 이 부분을 명확히 해야 할 것 같더라구요. TDD 는 개발자의 내공이 일정 수준 이상 되어야 한다는 걸 몸소 깨닫게 되었습니다. 일정 수준이 어느 정도인지는 사람 마다 다른 것 같지만, 제가 느끼기에는 기존의 UML 등을 이용한 설계 능력도 어느 정도 뒷받침 되고 소프트웨어 개발 프로세스에 대한 전반적인 시야도 있으며, 결정적으로 기존 개발 프로세스에 불만을 느낄 수 있는 정도의 실력이 있어야 합니다.
저는 그런 의미에서 TDD 를 자유롭게 쓸 만한 내공이 부족했습니다. 실무에 적용하면서 중간에 몇 번씩 기존 개발 방식으로 돌아가고 싶다는 유혹을 느꼈고, TDD 의 장점을 머리로만 이해했지 가슴으로 이해하진 못했기 때문입니다.
하지만, 이왕 시작한 거 끝을 봐야 겠다는 각오도 있었고, 지도 선배님의 드라이브도 강력했기 때문에 계속해서 멘토링을 받으면서 개발을 진행해 나갔습니다. 그러면서 약간 눈높이를 맞춰서 저에게 맞는 방식으로 접근법을 좀 더 체계화 해 보았는데요, 아래와 같은 방법입니다.
1. 먼저 프로그램 개발 전에 Use Case 를 PPT 로 작성 (UI 를 중심으로)
2. 작성된 PPT 를 바탕으로 사용자 시나리오를 다시 Word 로 작성 (행동 하나 하나를 분리)
3. Word 로 작성된 시나리오를 보고 사용할 디자인 패턴에 맞게 설계 (MVC, MVVM, ...)
4. 대략적인 UML 설계도와 Word 문서에 쓰인 시나리오를 참고하여 프로젝트 생성
5. 유닛 테스트 (예: gtest, ...) 적용
6. Word 로 작성된 시나리오를 보고 주석으로 테스트 코드 작성
7. 작성된 주석들을 보고 실제 테스트 코드 작성
8. 테스트 코드는 단계별 (예: V → C → M) 로 작성할 것
9. 테스트 실행 및 테스트 코드를 보면서 껍데기 목업 클래스 / 빈 메소드 구현
10. 전체 구조를 먼저 검토 후 다시 세부 구현들을 실제로 하나씩 구현하며 테스트
위의 순서에서 특히 저에게 와 닿은 것은 처음 1번과 2번 단계입니다. 저는 시각적으로 먼저 이미지화 해서 어떤 상황이나 구조를 이해하는 습관이 있는데, 정말 저에게 필요한 단계였습니다. 아무리 단순한 프로그램이라 하더라도 UI 를 그려보고 직접 사용자가 되어서 한 번 가상으로 테스트를 해 보는 겁니다. 그리고 이 걸 바탕으로 다시 Word 로 한 줄 한 줄 표현해보니 마치 그림 그릴 때 밑 그림을 그리는 것 처럼 상상이 훨씬 구체적으로 잘 되었습니다.
디자인 패턴을 선택하고 적용하면서 시나리오에 작성된 기능들을 대략적으로 구분하는 작업은 지도 선배님과 함께 진행하였는데요, 사실 위의 작업들 상당수를 함께 작업 하면서 궁금한 점은 바로 질문하고 쌍방 검토를 진행해 보았습니다. 특히 테스트 코드를 주석을 보면서 직접 작성할 땐 짝 프로그래밍을 도입해서 제가 코드를 작성하고 지도 선배님이 대략적인 방향을 알려주는 역할을 해 주셨는데요, 프로그래밍 노하우를 직접 전수 받는 느낌이었습니다! 굉장합니다!
제가 먼저 제 생각과 의도를 말하고, 이를 코드로 구현하면 지도 선배님이 이를 다시 검토하고 피드백을 줍니다. 그리고 다시 코드를 바꿔보고 제안 받은 것들에 대해 반영해 보면서 코드를 다듬습니다. 이렇게 다듬어진 코드는 제가 미쳐 생각하지도 못한 많은 문제들을 미리 발견 할 수 있도록 해주며 코드를 작성하는 노하우를 배울 수 있게 해줍니다. 마치 비기를 전수 받는 느낌이랄까요, 사부와 1대 1로 무공 연마를 하는 그런 느낌이었습니다.
좀 더 세부적인 단계를 나눠서 다시 TDD 를 접하고, 이 과정에서 지도 선배님과 상시로 피드백을 주고 받으면서 프로그램을 테스트 하면서 동시에 저 스스로의 지식과 노하우를 끝 없이 점검합니다. 분명히, 개발 속도는 아직까지도 굉장히 느리고 또 선배 개발자분의 노고가 필요한 일임에는 틀림 없지만 배우고 실행하는 저에겐 더 할 나위 없는 배움의 장이요, 내공을 단단히 쌓아 갈 수 있는 절호의 기회라 할 수 있겠습니다.
TDD 는 제가 생각 했을 때, 빨리 실패하고 빨리 수정하면서 개발 싸이클을 빠르게 가져가는 게 무엇 보다도 장점인 것 같습니다. 빨리 실패하기 위해서는 구현 전에 반드시 먼저 테스트를 해야 하고, 테스트를 잘 하기 위해서는 무엇 보다도 사용 시나리오를 제대로 확립하고 디자인 패턴에 따른 설계도 잘 해야 할 것입니다.
빨리 수정하기 위해서는 혼자서는 안됩니다. 내 코드를 다른 개발자가 보고 피드백을 줄 수 있어야만 합니다. 이왕이면 나 보다 더 뛰어난 선배 개발자님과 함께 할 수 있다면 좋겠지요. 첨삭 지도를 받지 못하더라도, 최소한 어떤 부분을 더 신경 써야 할지에 대해선 알 수 있을 겁니다.
TDD, 개념도 어렵지만 실천은 정말 더 어려운 것 같습니다. 혼자서 했다간 도중 하차하기 쉽상일 듯 합니다. 반드시 함께 할 사람이 있어야 할 것 같습니다. 아직 왕초보이지만, 계속 해 나가면서 배우고 또 깨닳은 것들은 부족한대로 공유하겠습니다. :)
0 Responses