테스트코드에 대한 생각

최근 항해 플러스 과정을 진행하면서 TDD로 과제를 진행하고 있다.

이제 겨우 2주 해보았지만, 생각정리겸 글을 쓴다.

우선 TDD에 대해 이야기하기 전에 테스트 코드에 대해 이야기해보려 한다.

 

 

테스트코드가 꼭 필요할까?

개발하기도 바쁜데 왜 테스트코드가 필요한가? 라고 하면 할말은 없다. (당장 생산성을 떨어뜨리는건 맞으니까...)

테스트코드도 리소스인데 그거 작성할바에 "잘" 짜고 몇번 테스트해보면 되는거 아닌가? 라고 해도 할말은...없다.

 

그런데... 개발을 진행하면서 잘 된적이 몇번이나 있던가?

이 글을 읽는 사람들 포함하여 대부분의 개발자는 그렇지 않을 것이다.

API 개발 과정을 생각해보자. 개발 -> 테스트 -> 리팩토링 -> 테스트 -> ...와 같은 과정을 거친다.

코드는 리팩토링을 거치며 변한다. 하지만 테스트는 변하던가?

 

지갑에 있는 돈을 사용하는 기능을 만든다고 가정해보자.

원화를 기준으로 아래와 같은 제한사항이 나올것이다.

• 사용하려는 금액은 가진 돈보다 적거나 같아야 한다.
• 정수 값만 금액으로 사용할 수 있다.

각각의 제한사항마다 필요한 Input은 다를것이다.

제한사항이 늘어날수록 API를 찔러보는 횟수는 늘어날것이고, 이는 반복적인 테스트를 유발한다.

사람은 망각의 동물이다. 반복하다보면 누락되는 테스트가 생기기 마련이다.

실수는 무조건 생긴다고 생각하고 최소한의 테스트코드는 작성해야하지 않나 싶다.

 

 

TDD가 정말 필요할까?

결론부터 말하자면, 테스트코드는 몰라도 TDD는 필수는 아니라고 생각한다.

물론 TDD도 장단점을 꼽자면 여러가지가 있긴 할거다.

 

장점으로는

1. 개발 초반부터 오류를 미리 잡아낼 수 있으며

2. 디버깅 시간을 단축시키며

3. 테스트코드 자체가 API 문서가 될 수 있다.

 

단점으로는

1. 시간이 오래 걸린다. (TDD에 익숙하지 않을수록 큰 단점으로 다가온다)

2. 테스트코드도 유지보수에 포함되기에 관리포인트가 늘어난다.

 

나는 위의 장점중에서 3번이 가장 큰 장점이라고 생각한다.

본인이 엣지케이스에 대해 얼마나 파악하고 있는지 되돌아 볼 수 있게 해준다.

또한 로직에 매몰되지 않고 설계와 인터페이스 중심으로 생각할 수 있는 기반을 마련해준다.

이것만으로도 할 가치가 충분하다고 느낀다.

 

 

 

물론 본인이 속한 회사 상황에 따라서 취사선택을 해야겠지.

테스트코드만 짜놓고 실제 로직 완성을 못하면 안되니까...

 

그냥 주절거려봤다 ㅎ