TDD 에 대한 고찰

개발조직을 이끌다보면,

여기저기서 TDD 에 대해 많이 거론되곤 했다.

과거의 회상을 기반으로 TDD 에 대한 나의 관점을 정리해 보려한다.

 

우선 집고 넘어가야할 것이 있다.

Test Code 를 작성하는 것과 TDD 는 다르다.

(Test Code 는 필!수! 이다. 다만, 테스트 커버리지는 정할필요성이 있다!) 

Test Code 의 경우 여러 기준점을 들 수 있지만 일반적으로 60~80%, 주요 도메인의 경우 90%까지 산정하기도 한다.

 

TDD 의 개발 프로세스를 보면,

1. 테스트를 가장 먼저 작성

2. 그 테스트를 통과하도록 코드를 작성

3. 테스트 코드 실행 후 오류발생 여부 확인(지정된 값이 나오지 않아도 오류로 표기된다.)

 

위의 과정으로 개발해 보았을때,

현실적인 문제에 직면한다.

1. 테스트 범위

2. 테스트 코드를 항상 먼저 작성해야하는가?

 

테스트 범위에 대해 언급하기 전에 Test Code 종류에 대해 조금더 설명하자면,

1. Unit Test(단위테스트) : 하나의 메쏘드로직을 테스트 하는 것 (외부 모듈 참조 시 Mock 으로 대처)

2. Intergration Test(통합테스트) : 여러 모듈이나 메쏘드를 테스트(but 외부 라우팅을 통해 테스트는 아님)

3. e2e Test (end to end 테스트) : 외부 라우팅을 통해 테스트 수행

 

TDD기반으로 고민을 해보았을때, 개발에 필요한 모든 메쏘드에 대해 단위테스트를 작성할 것인가?

(상당한 개발 비용이 발생할 것이다.)

그럼 통합테스트 기준으로만 작성할 것인가?

아니면 e2e 기준으로 작성할 것인가?

 

등의 테스트 커버리지라고 하는 테스트 범위에 대한 모호한 기준이 발생한다.

(적절한 테스트 코드가 없으면 오류발생으로 인한 또다른 손실이 발생은 한다!)

그럼 로직의 중요도와 복잡도의 측도로 판단할 것인가?

 

모든 코드를 단위테스트를 작성하고 독립적으로 구성하여(mock 최대한 활용), 

표면적이 좁고 외부 의존성을 가능한한 최소로 가지고 갈 경우,

우리는 또 다른 이슈에 직면하게 된다.

 

바로 하나하나의 메쏘드들은 이슈가 없었지만,

이를 통합적으로 테스트를 가져가게 되면, 이슈가 날 수도 있다는 것이다.

(참조하는 리턴값을 재처리 하는 과정에서 또는 의존성이 생기는 부분에서 발생)

 

의존성을 최소화한 단위테스트가 e2e 또는 통합테스트로 넘어오면서 타 묘듈과 

의존성이 발생하게 되고, 이러한 과정에서 단위테스트는 통과하였지만, 통합테스트는 통과하지 못하는 

경우가 생기고, 통합테스트, e2e 테스트 코드까지 작성하게 되면?

배보다 배꼽이 더 커지는 현상을 경험하게 된다.

 

github 내 PR 이든 Push 든, 이벤트가 발생할 때 테스트 코드를 실행하여,

오류가 있는지 없는지 판별하는 작업을 하게 되는데(자동세팅)

이때 걸리는 시간이 도커 빌드시간보다 길어진다.

 

즉, 단위테스트의 커버리지와 통합, e2e 테스트를 어디다 정목할 것인지

기준이 중요하다는 것이다. 

(기준을 잘 만들었다 해도 이를 개발자들이 잘 지키게 하는 것은 또 다른 과제이다.) 

 

그리고 두번째로 언급한 테스트 코드를 항상 먼저 작성해야하는가?

이또한 쉽지않다.

개발을 하다보면, 중간에 기획내용 수정이나,

기획단계에서 잡아내지 못한 아주 구체적이고 상세적인 이슈를 발견하는 경우가 빈번한데

이럴때 마다 테스트 코드를 수정해야한다.

(개발하는 량보다 테스트 코드 수정하는 시간이 더 길어질 수도 있다.)

 

거기에 Google 의 Small Test, Medium Test, Large Test 개념 까지 도입하면!

PR merge 이후에도 테스트 할 내역이 매우 많아진다(내용이 많아진다는 것은 곧 시간이 늘어남이고 이는 곧 비용이 늘어남을 의미한다!)

적용했을때의 비용과 이득에 대해 고민해볼 필요성이 커지게 된다.

 

그래서 실무에서의 TDD 적용은 쉽지않다.