Home TDD(테스트 주도 설계)
Post
Cancel

TDD(테스트 주도 설계)

TDD


TDD란 Test Driven Development의 약자로 테스트 주도 개발을 의미합니다. 반복 테스트를 이용한 소프트웨어 방법론 중 하나로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하며 구현하는 방법으로 소프트웨어를 개발하는 것입니다.

단위 테스트 : 가장 작은 한 단위만을 테스트하는 것 (일반적인 단위는 Class)

TDD 개발 주기

  • Red : 실패하는 테스트 코드 작성하기
  • Yellow : 테스트 코드를 성공시키기 위한 실제 코드 작성하기
  • Green : 위 두 단계에서 추가되거나 변경된 코드를 리팩토링하기.

즉, TDD는 추가하고 싶은 기능을 구현하기 위해 실제 코드를 먼저 작성하는 것이 아니라 테스트 코드부터 작성하고, 그 다음에 테스트 코드가 실패하지 않도록 실제 코드를 작성합니다. 이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의하면서 불필요한 설계는 피하고, 정확한 요구 사항에 집중할 수 있습니다.

일반적인 개발 방식 vs TDD

일반적인 개발 방식이 자체 버그 검출 능력과 소스코드의 품질을 저하시키고 자체 테스트 비용이 증가하는 이유는 어느 프로젝트든 초기 설계가 완벽하지 않기 때문입니다. 고객의 요구사항의 변화로 인해 코드를 재설계하는 과정에서 개발자의 의도와는 다르게 불필요한 코드가 남거나 중복되는 코드가 생성될 가능성이 높아집니다. 그리고 이렇게 생성된 전체 코드에서 작은 기능 수정을 하더라도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워집니다. 이는 결과적으로 소스코드 품질 저하는 물론 작은 수정에도 모든 기능을 다시 테스트해야 하는 문제가 발생해 자체 테스트 비용이 증가될 수 있습니다.

하지만 TDD는 항상 테스트 코드를 작성하고 실제 코드를 작성하는 순서로 진행되기 때문에 설계 단계에서 코드의 목적을 미리 정의해야 하고 무엇을 테스트 할지 미리 단위 테스트를 적을 수 있습니다. 그리고 그 과정에서 발생하는 여러 에러 상황에 대해서도 테스트 케이스를 작성할 수 있어서 이후에 통과하는 실제 코드가 작성된 이후엔 자연스럽게 에러가 줄어들고 어느 부분에서 발생하는 에러인지 명확하고 쉽게 찾아낼 수 있습니다. 이런 장점을 통해 자연스럽게 테스트 비용이 절감됩니다.

TDD의 장점

  1. 보다 튼튼한 객체 지향적인 코드 생산
    TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄집니다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 됩니다.
  2. 재설계 시간의 단축
    테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 됩니다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있습니다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있습니다.
  3. 디버깅 시간의 단축
    이는 유닛 테스팅을 하는 이점이기도 한데, 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모든 레이러들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있습니다.
  4. 테스트 문서의 대체 가능
    주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만듭니다. 하지만 이것은 단순 통합 테스트 문서에 지나지 않습니다. 그래서 TDD를 하게 될 경우, 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있습니다.
  5. 추가 구현의 용이함
    개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것입니다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있습니다.

결국 TDD가 주는 궁극적인 장점은 모든 기능에 대해 먼저 테스트를 작성하는 것이며, 이를 통해 실제 작성한 코드를 언제나 리팩토링하고 정리할 수 있다는 자신감을 얻는 것입니다.

TDD 단점

하지만 이러한 장점에도 모든 기업이 TDD를 따르지는 않습니다. 그 이유는 다음과 같습니다.

  1. 생산성 저하
    아무래도 2개의 코드를 처음부터 만들어야 하고, 중간중간 테스트를 하면서 고쳐나가는 방식은 개발 시간이 늘어날 수 밖에 없습니다. 그렇기에 많은 기업들이 TDD의 도입을 꺼려하는 것입니다.
  2. 상대적으로 높은 초기 비용
    일반 개발 방식보다 초기에 드는 개발 및 테스트 비용을 많이 요하게 됩니다.

그러나 일정 시점이 지나면 TDD를 통해 방대한 코드가 생성된 프로젝트에선 수많은 테스트 케이스를 작성해두었기 때문에 오히려 테스트 비용을 절약하고 효율적인 작업이 가능할 것입니다.

참고 자료


  • https://wooaoe.tistory.com/33
  • https://media.fastcampus.co.kr/knowledge/dev/tdd/
  • http://www.yes24.com/Product/Goods/75189146
This post is licensed under CC BY 4.0 by the author.

[football] 환경에 따른 application.yml 파일 구분

[football] Setter를 사용하지 않고 환경변수 호출을 위한 고민