Test-Driven Development 리뷰를 시작하며…

기본

일반 개발자가 작동하는 깔끔한 코드(clean code that works)를 얻기 위한 가장 쉬운 방법은?

테스트주도 개발 표지

테스트주도 개발, Kent Beck

누군가 이런 질문을 한다면 저는 TDD라고 답하겠습니다. 물론 TDD가 쉽다는건 아니고 어떤 정량적인 측정 방법으로 자신의 실력을 확인하는건 불가능 하겠지만 TDD를 사용하기 이전과 이후는 확실히 무언가 달라졌다 라고 생각합니다.

특히 어느 부분이 달라졌냐고 물어본다면 바로 코드에 대한 확신이라고 하겠습니다.

저는 처음으로 100라인이 넘게 코딩한 프로그램이 뭔지 기억합니다. 불과 1년도 지나지 않았으니까요. 그런데 그 프로그램에는 테스트라는게 없었습니다. 그냥 main() 에서 실행해서 하나하나 눌러보는게 전부였었죠. (GUI 프로그램이었거든요.)

나중에 프로그램이 너무 복잡해 져서 어느 부분이 어떻게 돌아가는지 모를 지경이 됐을 때 제가 한 첫 번째 행동은 변수 이름을 바꾸는 것이었습니다. 지금 생각해보면 이게 리팩토링의 시작이었던 것 같네요. 그리고 또 직접 돌려보면서 혹시 꼬인게 없는지 하나하나 테스트를 했더랬죠.

그렇게 main() 에서 수없이 프로그램을 돌려봤음에도 불구하고 마지막에 교수님께 제출할 때까지 얼마나 초조했는지 모르겠습니다.

시간이 흘러 JUnit을 접하게 됐고 지금은 TDD를 공부하고 있습니다. 지금 1년 전과 달라진 것은 적어도 테스트를 작성한 부분에 있어선 그런 초조함이 없다는 겁니다. 왜 그럴까요? 틀리면 틀렸다고 맞으면 맞다고 대답해줄 자동화 테스트 프레임워크가 있기 때문입니다. 테스트에 헛발질을 한게 아니라면 JUnit이 맞다면 맞는거죠. 틀렸다고 하면 고치면 됩니다. 뭐가 걱정인가요?

TDD는 테스트를 먼저 만들면서 프로그램을 구체화 시키는 방법론 입니다. 장점은 일단 테스트가 많으니까 견고하다는 거겠죠. 단점은 일반적인 방법을 거스르기 때문에 어렵다는 겁니다. 추가로 테스트 툴이나 라이브러리에 대한 어느 정도의 학습이 필요합니다. 잘못하면 배보다 배꼽이 더 큰 격일지도 모르죠. 그런데 그건 실무하는 사람들 얘기고 저같은 학생은 좋은 습관을 들일 수 있는 훌륭한 방법론이라고 생각합니다.

리뷰하면서 수필 쓸 생각은 없기 때문에(…) 차차 리뷰를 진행하면서 TDD에 대해 간단히 정리해 볼 생각입니다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중