TDD를 한번 제대로 해 보았다

회사에서 하는 업무 특성상, 여기저기 애드 네트워크(Ad-Network)에서 데이터를 가져오는 데이터 크로울러를 자주 만드는 편이다. 새롭게 추가된 애드네트워크 데이터를 가져올 크로울러를 만들게 되었는데, 한번 제대로 된 TDD(Test-Driven Development)를 적용해 볼 기회가 있었다. 이전에는 중요한 일부분만 테스트하는 유닛테스트를 작성하거나 기본적인 flow를 테스트하는 integration test를 작성했다면, 이번에는 Red, Green, Refactor 순서의 TDD를 해보고자 했다.

TDD란? (Red, Green, Refactor)

• 충분히 fail이 발생할 만큼의 unit test를 작성한다.
• unit test가 pass 할 정도의 코드를 작성한다.
• 코드를 리팩토링한다.
• 위 3개의 스텝을 계속 반복한다.

다 필요 없고 결론부터

• TDD는 생각보다는 힘들다.
• 빠르게 개발하고 iterate 해야 하는 상황에서는 매번 TDD 방식으로 개발하기는 어렵다.
• 하지만 1) 테스트가 가능하고 modular한 구조를 잡아야 할 때, 2) 틀리면 안 되는 비지니스 로직 구현 할 때, 3) 리팩토링을 앞두고 있을 때의 TDD의 역할은 눈부시다.

어려웠던 점

• 뭘 만드냐에 따라 다 다르겠지만, HTTP 통신과 DB mocking, 그리고 mock data가 필요할 때는 일이 매우 귀찮아진다.
  • 하지만 mocking이 필요할 때는 그냥 해야 한다.
• 테스트를 작성하고, feature 코드뿐만 아니라 테스트 코드도 리팩토링하고 관리하는 데에 공수가 많이 들어간다.
  • 내 경우, crawler를 하나 만드는 것 만큼의 공수가 test case 짜는데 들어간 것 같다.

TDD를 통해 얻은 수확

• 테스트가 가능하고, 더 나아가 테스트하기가 쉬운 형태의 코드 구조를 작성하게 된다.
  • 내 케이스의 경우, 기존과는 달리 조금 더 논리적이고 테스트가 쉬운 새 형태의 crawler 구조가 자연스럽게 출현하게 되었고, 이 템플릿을 그대로 다른 crawler에 적용했다.
    • 기존 코드를 새로운 구조로 바꾸었더니, 전반적으로 CPU resource뿐만 아니라 네트워크 호출 수를 제법 줄일 수 있었다.

TDD의 단점

• 공수가 많이 들어간다. 또한 feature 코드와 동일하게 관리를 해야 한다.

어디서 TDD를 쓰면 좋을까?

다음 3가지 문제에 매우 적합하게 쓸 수 있을 것 같다.

1. 동일한 템플릿을 따르는 코드가 많을 경우

• TDD 적용 시, 어쩌면 기존보다 더 간결하고 테스트하기 좋은 새로운 템플릿을 도출할 수 있을 것이다.

2. 실수가 용납이 안 되는 비즈니스 로직 구현 시

• 정산 시스템과 같이 틀리면 인생이 매우 힘들어지는 코드는, TDD 방식으로 접근하고 많은 mock data와 unit test로 무장시켜라.
  • 상용에서 문제 터지는 것보다 지금 테스트 짜느라 고생하는게 신체/정신 건강에 훨씬 좋다. (개발자라면 다들 최소한 한 번 정도는 경험하셨을 듯…ㅜㅜ)

3. 리팩토링을 앞두고 있을 시

• 새 코드가 기존 코드와 동일하게 작동할지에 대한 보증이 필요하다. 위와 마찬가지로, 상용 배포 후 고생하는 것 보다 지금 고생하는 것이 훨씬 낫다.