brunch

You can make anything
by writing

C.S.Lewis

by 정윤상 Jul 19. 2021

Test Driven Develop에 대한 고민

많은 개발팀에서 TDD에 대해 고민하고 많은 토론을 수행하고 있다. 한때 TDD는 개발의 바이블같은 분위기도 만들어졌었고 최근에는 부정적인 의견도 많이 나오는것 같다.

오늘은 내가 생각하는 TDD에 대해서 이야기하고 정리해보는 시간을 가지기 위해 글을 작성한다. 이직 후 처음으로 작성하는 글이다. 적응하는 시간을 가지느라 글을 작성하지 못했는데 앞으로는 많은 글을 작성하려고 한다. 그럼 시작해보자!

1. TDD를 처음 봤을때 느꼈던 환상

처음 TDD를 접했을때의 느낌은 "난 지금까지 무엇을 한거지?"였다. 그만큼 혹하고 좋은 아이디어를 가진 의견이었기 때문이다. 내가 원하는 기능을 가장 빠르고 정확하게 구현하면서 버그를 최소화하는 개발법이라...이런 단면을 봤을때는 정말 최고의 개발이론이다.

항상 개발을 진행하면서 느꼈던것은 난 정말 코드를 효율적으로 작성하고 있는지였다. 하지만 이런 의문은 TDD가 해결해주었다. 테스트를 먼저 작성하기 때문에 테스트 가능하도록 코드를 설계하게 되고 이런 흐름은 로직을 더욱 탄탄하고 효율적으로 만들도록 강하게 압박한다.

테스트가 가능하도록 코드를 설계하게 된다면 생각보다 더 체계적으로 구조를 잡게 된다. 단일 책임을 가지는 함수들을 생산하기 시작하고 이는 자연스럽게 여러 패턴으로 진화하게 된다.

2. Unit Test VS TDD

실제 TDD와 유닛테스트를 동일선상에 두는 경우를 몇몇 봤지만 실제로는 아예 다른 개념이다. 유닛테스트는 하나의 Function또는 로직을 검증하는 과정을 의미한다. 하지만 TDD는 이러한 테스트 코드를 먼저 설계하고 구현을 진행하는 개발 "방법 이론"이다. 철학에 가깝다고 이야기하는게 좋을것 같다. 이런 철학적인 요소를 이해하지 못하면 실제 TDD를 한다고 하기에는 무리가 있지않나 싶다. 내가 사용하는 기술이 어떤 위험요소와 장점이 있는지 알지못한다면 그것이야 말로 위험하다할 수 있다.

때문에 TDD를 기반으로 개발한다고 이야기하는 팀들 또한 실제로는 그렇게 수행되지 못하는 경우도 상당히 많이 있다. 또 TDD에 대해서 다양한 단점들과 문제점도 많기 때문에 적당히 몇가지 철학만 차용해서 사용하는걸 권장한다. 이는 개인적인 의견이니 참고만 바란다.

3. TDD의 한계와 내가 생각하는 사용법

TDD는 생산성의 측면에서 봤을 때 정말 좋은가?라는 의문이 따른다. 물론 TDD를 이용해 완성도 높은 코드를 생산하고 이는 결국 절대적인 시간을 줄일것이다라고 이야기할 수 있지만 이는 TDD가 무조건 완성도 높은 코드를 생산한다고 이야기할때나 할 수 있는 주장이다. 실제로 TDD는 어렵다.

테스트를 먼저 작성하는 행위는 일반적으로 익숙하지 않기 때문에 테스트 방법을 설계하는 것 조차 어렵기 때문이다. 그리고 유저가 절대 발생시키지 못할 버그를 우리는 테스트로 처리하려한다. 난 이 부분때문에 TDD를 맹신하는 사람을 좋아하지 않는다. 테스트는 테스트일 뿐이다.

또한 개발자가 돈을 받는 이유는 무엇인가? 테스트를 짜기위해서인가? 아니면 소프트웨어를 생산하기 위해서인가? 정답은 모두가 알고있다.

최고의 팀은 TDD의 몇가지 철학을 적절히 반영하고 생산성을 저해하는 부분을 무시한다. 각각의 개발자들은 테스트에 대해 어떻게 생각해왔는지 스스로 생각해보고 적용할 필요가 있다.

물론 내 생각이 정답은 아니다. 경험에 의한 하나의 의견이기 때문에 나중에는 다른 생각을 가질 수 있다. 그럼 오늘은 여기서 끝!

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari