Enjoy My Posts

내가 생각하는 TDD의 장단점

Posted on Apr 03, 2021 By Geunwon Lim

일단 이 글은 TDD와 관련된 책을 읽지 않고 쓰는 것이라 지식이라기보다는 하나의 견해이다. TDD와 관련된 경험으로는 TDD 연습을 위해 하나의 작은 프로그램을 TDD로 만든 경험이 있다. 그리고 현재 프로젝트를 하는 와중에 정말 가끔씩 테스트를 먼저 짠다.

현재 내가 생각하는 TDD는 팀 프로젝트를 할 때 전반적인 코드 퀄리티를 높이기 위한 개발 방법이다.

TDD의 장점

흘린 글씨는 좀더 TDD를 하며 새롭게 적은 것이다.

내가 생각하는 TDD의 장점은

  1. 테스트를 전제하기에 자연스럽게 테스트 커버리지가 올라간다.

    테스트 커버리지가 높다고 좋다고 할 순 없겠지만, 낮은 것보단 높은 게 나을 것 같다. TDD를 통해 테스트가 주는 일반적인 장점(코드를 신뢰할 수 있음, 코드를 새로 보는 사람이 쉽게 코드를 이해할 수 있음, 불안에 떨지 않고 리팩토링 할 수 있음 등)이 가장 먼저 생각할 수 있는 가치인 것 같다.

  2. 구현 대신 인터페이스에 집중하게 한다.

    테스트를 먼저 짜려면 일단 뭐가 인풋이고 뭐가 아웃풋인지부터 정해야한다. 복잡한 구현에 대한 고민은 뒤로 미룰 수 있게 된다.

  3. 지금 하고 있는 게 뭔지 까먹지 않게 해준다.

    사실 이거는 최근 개인 프로젝트를 하면서 든 생각이다. 근본적으로 A를 해결해야하는데, A를 해결하기 위해 B를 하고, C, D, E… 등을 하다보면 가끔 ‘지금 뭐하고있었지?’ 라는 생각이 든다. 이거는 너무 개인적이라 다른 사람들은 보통 안그럴 것 같긴 하다. 근데 나는 가끔도 아니고 자주 그랬다. 그러다보니 곧은 길을 두고 멀리 멀리 돌아가는 경우가 생겼다. 사실 이거는 굳이 테스트를 짜지 않아도 그냥 옆에 적어놓기만 해도 같은 효과를 누릴 수 있기에 TDD의 장점이라고 하기엔 뭐한 것 같지만… 길을 잃고 나서 ‘아 지금 테스트 먼저 짰으면 헤매지 않았겠다’ 고 생각하는 경우가 있어서 적어본다.

  4. 더 빠르게 디버깅할 수 있다.

    내가 하려는 것이 뭔지 알고 있다는 전제하에, 실패 테스트를 작성하자마자 디버깅 범위는 그 안으로 한정된다. 그러다보니 부수적으로 안정감을 주는데, 내 경우 실패 테스트를 짜자마자 ‘게임 끝났다’고 생각이 들만큼 마음이 편해졌다.

  5. 안정감을 준다.

    프러덕션 코드를 먼저 짤 때는 “이게 될까?”라는 생각을 하며 짜곤 했다. 근데 TDD를 하는 순간 그런 생각이 들지 않았다. 왜냐면 안되는 게 당연하니까.

    또한 위에서 언급한 빠르게 디버깅할 수 있다는 맥락에서, 안정감을 더했다. 지금 안되는건 당연하고, 코드를 짜기만 하면 디버깅을 빠르게 빠르게 할 수 있기에 코드를 짜자 마자 ‘게임 끝’이라는 생각이 든다.

    이러한 맥락에서, TDD는 ‘일단 되게 하자’ 마인드에서 비롯된 느낌이다. 뭔가가 안될 때 운이 좋으면 트라이해보고 싶은 리스트가 나온다. 이것저것 공부하고 나서 완전히 알고난 후 코딩해도 되겠지만, 그거 다 공부하다보면 느려지는 건 어쩔 수 없다. 일단 코드 짜겠다, 그리고 디버깅하면서 해결되면 나이스 느낌. 안되면 어쩔수 없이 공부해야하고.

  6. 왔다리 갔다리 하기 편하다.

    IDE의 활용과 겹쳐지며, 일단 막 코드 짜다가 갑자기 다른 생각이 들면 바로 딴걸 하고 다시 코드로 돌아가기 쉽다. 코딩을 할 때는 “지금 뭐해야해”만 집중하니, 갔다 와도 뭐하고 있었던지만 보이고, 또한 IDE가 친절히 하고 있던 곳 밑 지금 이상한 부분을 빨간 줄로 표시해주니 다시 바로 코드에 집중할 수 있다. 코딩을 하다가 바로 TDD의 장점을 문서화하고 있는 게 그에 대한 반증이다.

  7. 더 재밌다.

    잘 모르는 부분을 삽질할 때 짜증이 올라오곤 한다. 오랫동안 삽질하다보면 하기 싫어진다. 근데 TDD를 하면, 문제가 완전히 해결되지 않았더라도 커밋 가능하고, 았싸 커밋 하면서 재미를 느낄 수 있다. 이건 사실 별거 아닌것같기도 하지만, 장기적인 관점에서 꽤나 중요한 부분이라고 생각한다.

TDD 시 주의사항

  1. 내가 짠 모든 프러덕션 코드에 대해 테스트를 짜야 한다는 부담에서 벗어나는 게 좋을 것 같다. 기존에 TDD의 큰 단점 중 하나로 생각하는 것이 낫 TDD보다 더 느리다는 것이었다. 당연히 프러덕션 코드에 버그가 없다는 것을 가정할 때, 테스트 코드를 안짜는게 짜는거보다 빠를 수밖에 없다. 심지어 다 짜려고 하다보면 짜다보면 자괴감이 드는, 무의미한 테스트 코드를 짜게되는 경우가 있다. “내가 지금 하려고 하는 것”에 대한 테스트를 짜는 게 TDD의 핵심인 듯하다.
  2. TDD가 좋다고 느껴도 항상 TDD로 하려고 하는건 그다지 좋은 것 같지 않다. 상황에 따라 “이건 TDD다” 싶을 때 테스트 먼저 짜는 게 좋을 것 같다.

TDD의 단점

  1. 너무 어렵다.

    내 개발 실력이 부족해서겠지만, TDD는 너무나 어렵다. 익숙해지려면 진짜 한참 걸릴 것 같다. TDD로 작은 프로그램을 만들 때, 오로지 자바 언어만으로 프로그램을 만들었었는데도 불구하고 테스트를 썼다 고쳤다를 반복했다. 만약 TDD로 짜지 않았다면 시간을 1/3 정도로 줄여 같은 코드를 짤 수 있었을 것 같다. 내가 만들지 않은 기술을 쓰려고 할 때는 더 어려웠다. 일단 기술의 동작 방법부터 익혀야 뭐를 할 수 있기에, 공부 후 테스트를 짜면 ‘내가 이 기술을 잘 쓰고 있는지 확인’하는 용도로는 좋았지만, 현재 내가 생각하는 TDD의 핵심 가치인 ‘인터페이스에 집중하게 한다’와는 거리가 멀어지는 것 같다.

  2. 단점이라고 하기엔 적절하지 않을수도 있지만, TDD를 통해 얻을 수 있는 것을 TDD를 하지 않고도 얻을 수 있다.

    인터페이스에 집중하기? 테스트를 먼저 짜지 않더라도 인터페이스에 먼저 집중할 수 있다고 생각한다. 테스트 커버리지, 길을 잃지 않게 해주기 등 다른 것들도 굳이 TDD하지 않더라도 얻을 수 있는 가치라고 생각한다.

종합적으로 생각했을 때, TDD가 많이들 얘기하듯 엄청나게 좋은건가? 라고 생각했을 땐 아직 그렇게 생각하지는 않는다. 좋은 것 같다. 다만 다수의 팀원들이 참여하는 프로젝트에서는 코드 품질을 유지하기가 좀 더 쉬울 것 같다. 관리자 입장에서 ‘TDD로 하세요’라고 하면 일단 커버리지는 올릴 수 있고, 나와 같이 아직 실력이 부족한 개발자들도 ‘일단 인터페이스부터 고민하게’ 할 수 있다. 그리고 특정 상황에서 개발을 더 빨리 할 수 있게 도와주는 것 같다. 심지어 더 재밌다.