TDD(Test-Driven Development)란?

• TDD란?
• TDD 장점
• TDD 단점
• Reference

TDD란?

기존의 개발 프로세스

TDD 개발 프로세스

• TDD의 경우 테스트 코드를 작성한 뒤에 코드를 작성한다.

• 때문에 보다 정확한 프로그래밍 목적을 디자인 단계에서 반드시 미리 정의해야만 하고

• 또 무엇을 테스트해야 할지 미리 정의해야만 한다.

• 프로그래밍 경험이 있는 개발자라면 누구나 공감할 수 있는 것이 가끔 코드를 작성한 뒤에 테스트를 하면서

• “맞아! 원래 이걸 의도한 것이 아니었는데” 하면서 깨닫고 다시 작성한 코드를 수정하는 경우가 많이 있다.

• 이것을 방지 할 수 있다는 것이 TDD의 하나의 큰 장점 중에 하나이기도 하다.

TDD 장점

• 그렇다면 TDD의 가장 큰 장점은 아마도 높은 퀄리티의 소프트웨어를 보장한다는 것이다.

• 그렇다면 높은 퀄리티의 소프트웨어는 어떻게 정의할 수 있을까?

• 먼저 기획을 떠나서 개발자의 역할만 놓고 본다면 절대 에러나 버그가 없어야 한다는 것이다.

• 두 번째로는 추가적인 요구사항이 있을 때 손쉽게 그 요구사항을 반영해줄 수 있어야 한다는 것이고

• 마지막으로 누가 그 코드를 봐도 손쉽게 이해하고 수정할 수 있어야 한다는 것이다.

• 바로 TDD는 정확하게 이 세가지 사항을 만족시켜 준다.

보다 튼튼한 객체지향적인 코드 생산 가능

• 테스트 코드를 먼저 작성한다는 것은 하나하나의 기능들에 대해서 철저히 구조화 시켜 코드를 작성한다는 것을 뜻한다.

• 나도 모르게 디자인 패턴들을 하나하나 적용하고 인터페이스들을 이용해서 느슨한 결합을 실현시키는 자신을 발견하게 된다.

• 그 이유는 TDD가 코드의 재사용성을 보장해야만 가능하기 때문에 그렇다.

• 즉 우리가 테스트 코드를 작성할 일이 없을 경우에 한 메서드 안에 여러 가지 기능이 혼합되어 이용해도 무방하다.

• 아니 좀 더 솔직하게 우리가 코드를 작성하면서 실제로 이 코드는 재사용이 되지 않는다라는 가정으로 작성하는 코드가 많을텐데

• 실제로 어떤 기능을 2~3번 호출한 후에야 객체화하거나 메서드화 시키는 경우가 많다.

• 하지만 TDD는 모든 코드가 재사용성 기반으로 작성되어야 하기 때문에 보다 튼튼한 코드 생산이 이루어 지게 되는 것이다.

재설계 시간의 단축

• 앞에서 설명한 것처럼 테스트 코드를 먼저 작성하기 때문에 내가 지금 무엇을 해야 하는지 분명히 정의를 하고 시작하게 된다.

• 때로는 우리가 코드를 작성하면서 삼천포로 빠지는 경우가 많다.

• 내가 뭘 하려고 했었지? 하면서 코드 정체성의 혼란을 가끔 마주하면서

• 디자인을 다시 뜯어 고치고 아까운 코드를 지울 수 없어 그냥 주석을 달아 두고 괜히 라인수만 차지하게 되는 경우를 수없이 경험헸다.

• 하지만 TDD에 익숙해 지는 순간 이러한 경험은 이제 그저 추억 속으로 묻히게 된다.

• 테스트 코드를 작성하면서 인터페이스나 클래스의 구조들을 많이 수정하게 된다.

• 만약 테스트 코드가 아니라 실제 구현 코드를 작성하면서 이 작업을 한다면

• 구현하고 있는 코드들 또한 고쳐야 하는 문제를 유발하게 된다.

• 개인적인 경험에 비추어 보자면 실제로 초급 개발자와 중고급 개발자의 차이는

• 얼마만큼 예외 상황을 많이 알고 있느냐의 차이로 나누어 지기도 한다.

• 여기서 만약 먼저 테스트 시나리오들을 정의하게 되면

• 그만큼 필요한 예외 상황들을 먼저 상의할 수 있게 된다.

디버깅 시간의 단축

• 이것은 통합 테스팅이 아닌 유닛 테스팅을 하는 이점이기도 하다.

• 아래서 보다 정확한 논리를 설명할 것이지만 먼저 간단하게 설명하자면

• 우리는 각각의 모듈 별로 테스트를 자동화할 수 있는 코드가 없다면

• 특정 버그를 찾기 위해서 모든 레벨(레이어)의 코드들을 살펴봐야 한다.

• 예를 들어 사용자의 데이터가 잘못 나온다면 DB의 문제인지 비즈니스 레이어의 문제인지 UI 단의 문제인지

• 실제 모든 레이어들을 전부다 디버깅할 필요 없이 자동화 된 유닛테스팅 결과로 우리는 손 쉽게 찾아 낼 수 있다는 것이다.

에자일과의 시너지 효과

• 보다 정확하게 말하자면 BDD(Behavior-Driven Development)를 적용하는데 있어서 큰 시너지 효과가 있다.

• BDD는 행위(동작) 중심적인 방법으로 개발을 진행하는 방법론인데

• 개발자 디자이너 그리고 기획자 모두 사용자 입장으로 같은 목표로 가지기 위함이다.

• 예를 들어 회의를 할 때도 항상 개발자는 기술적인 관점으로 어떤 업무를 해석하는 경우가 많은데

• 이것을 어느 정도 완화시켜 줄 수 있기 때문에 도입한다.

• 즉 TDD를 진행하면 항상 그 테스트 요소들이 사용자 관점으로 정의되고 진행되기 때문에 보다 튼튼한 개발 프로세스를 만들게 된다.

테스트 문서의 대체가능

• 주로 S.I 프로젝트를 진행하다 보면 어떤 요소들이 테스트 되었는지 테스트 정의서를 만들고는 한다.

• 이것은 단순 통합테스트 문서에 지나지 않는다.

• 즉 내부적인 하나하나의 로직들이 어떻게 테스트 되었는지 제공할 수 없다.

• 하지만 TDD를 하게 될 경우에 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.

추가 구현의 용이함

• 개발 뒤에 어떤 기능을 추가할 때 가장 우리를 번거롭게 하는 것은

• 이 기능이 기존의 코드들에 얼만큼 영향을 미치게 될지 모르기 때문에 다시 모든 코드들을 테스트 해야 된다는 점이다.

• 하지만 유닛 테스트로 자동화 될 경우에 우리는 수동으로 모든 테스트를 다시 진행해야 되는 시간적인 낭비를 줄일 수 있다.

TDD 단점

• 그렇다면 단점들은 무엇일까?

• 먼저 코드 생산성이 가장 꺼림직한 문제일 수 있다.

• 코드 퀄리티 보다는 빠른 결과물을 원하는 환경이라면 쉽게 도입이 어려울 수 있다.

• 왜냐하면 개발자들이 TDD를 공부해야 하고 추가적으로 테스트 코드를 작성해야 하기 때문이다.

• 처음에는 익숙해지기 위한 시간 때문에 1-2달은 적응시간이 걸린다.

• TDD가 최소한의 객체지향 프로그래밍을 요구하는 이상 보통 1~2년 차 개발자라도 조금 어렵다는 생각이 들 수 있다.

• 때문에 객체지향에 올바른 이해를 가지고 있는 리드 개발자가 TDD 프로젝트를 리드해 갈 필요가 있다.

• 추가적으로 데드라인이 잡히면 도입하는데 힘든 점이 있다.

• 갑을병정 내려가는 프로젝트일수록 퀄리티 보다는 개발기간과 타이밍이 중요하기 마련이고

• 또한 소프트웨어에서 주인의식을 가지기 힘들 수 있기 때문이다.

• 이런 단점들이 있다고 하더라도 개발자의 커리어에 있어서는 TDD 도입은 중요하다.

• 먼저 자신의 객체지향적인 코딩 능력을 향상시킬 수 있기 때문이다.

• 더욱이 S.I회사가 아닌 자력 소프트웨어를 만드는 경우에서는 더욱더 그렇다.

• 회사의 입장에서도 처음 TDD의 도입에 대한 실이 많아 보일 수 있지만

• TDD 도입을 통하여 보다 튼튼한 소프트웨어를 만들 수 있을뿐더러 향후에 관리에도 더 용이하게 된다.

Reference

• TDD(Test-Driven Development)란?