Test Driven Development

TDD란 테스트 케이스를 이용해 작은 단위로 요구사항을 정의하고 해당 테스트 케이스가 통과되도록 코드를 개선하여 빠르고 짧은 주기로 코드를 완성하는 방식으로 개발을 진행하는 방식입니다. 그 유명한 켄트 벡 할아버지(Kent Beck)에 의해 처음 소개되었으며, 현재 우리나라에도 꽤 전파되어 어떤 개념인지는 많은 개발자들이 이미 알고 있다고 생각합니다.

TDD의 핵심은 기능의 추가, 수정, 삭제 등 요구사항에 변화가 생겼을 경우 해당 요구사항에 맞도록 테스트 케이스를 정의하고 해당 테스트 케이스가 통과되도록 코드를 수정하여 빠르게 하나씩 완성시켜 나가는 것입니다.

TDD의 장점으로는 요구사항이 변경되어도 항상 테스트 케이스를 만족하는 코드를 만들기 때문에 사이드 이펙트(side effect)를 바로 감지할 수 있고, 안심하고 코드를 짤 수 있도록 개발자들에게 확신을 줄 수 있다는 것입니다.

단점으로는 테스트 케이스를 정의하여 작성하는 시간이 추가되고, 생각하지 못했던 테스트 케이스에 대해선 대응을 하지 못한채로 코드에 대해 확신을 가질 수 있기때문에 위험성이 완전하게 제거되지 않는 경우가 생길 수 있다는 것입니다.

TDD가 관심을 받고 있는 이유는 사이드 이펙트를 미리 감지하여 개발자의 실수를 줄여주고 코드에 확신을 가져 서비스를 지속적이고 안정적으로 운영 할 수 있도록 도와주기 때문입니다.

하지만 모든 팀에서 적용을 바로 하지 못하는 이유는 TDD를 프로젝트 중반에 도입하기엔 큰 무리가 따르고, 급한 일정 속에서 테스트 작성을 뒤로 미루는 상황이 발생하면서 나중에 건들 수 없는 상태가 되는 등 수 많은 변수가 발생하기 때문입니다.

따라서 TDD를 도입하기 위해선 프로젝트 초반부터 설계를 잘 하여 코드의 재사용성 및 의존성을 줄여 놓아 개발 일정에 차질이 생기지 않도록 미리 대비하고, 모든 팀원들이 TDD에 대한 인식이 확립되어 함께 노력하며 코드를 관리해야 가능하다고 생각합니다.

TDD방식이 팀의 개발문화로 자리잡는다면 새로 합류한 팀원이나 자신의 도메인이 아닌 부분을 서포트할때 코드의 사이드 이펙트를 바로 감지할 수 있어 좀 더 안정적으로 개발을 진행할 수 있다고 생각합니다.

TDD는 절대반지는 아니지만 안정적인 개발과 서비스를 위해 채택을 고려해보기엔 충분히 매력적인, 어쩌면 필수적인 방식이 아닐까 생각합니다.