Software Testing - TDD(Test Driven Development)

TDD란?

테스트 주도 개발.

테스트 코드를 먼저 만들고 테스트에 통과할 수 있는 코드를 짜는 개발 방식이다.

 

TDD에서는 실패하는 테스트 코드를 작성하기 전에 실제 코드를 작성하지 않는다.

테스트 작성을 통해 실제 코드에 필요한 핵심 기능을 명확하게 파악하고

필요한 것만 빠르게 개발하는 것이 목적이다. 

 

TDD 개발주기는 다음과 같다. 

 

1) 실패하는 테스트 코드 작성 : 처음에는 테스트 코드가 실행/컴파일조차 되지 않을 것이다. 그래도 괜찮다.

2) 무슨 수를 써서든 테스트를 통과할 수 있는 실제 코드를 빠르게 작성 

3) 리팩토링(중복 제거 등)

 

일반 개발 방식 VS TDD

일반 개발 방식

일반 개발 방식은 다음과 같이 진행된다.

유저 요구 사항 분석 => 기능 설계 => 개발 => 테스트 => 배포

 

유저의 요구사항은 계속 바뀔 수 있고, 처음부터 설계를 완벽하게 할 수도 없다.

이런 이유로 개발자는 계속 코드를 수정해야 되는데 

수정하면서 불필요한 코드가 남거나 중복되기 쉽다.

이렇게 생성된 코드는 재사용하기도 어렵고 관리도 어렵다.

 

또 모든 개발을 완료한 후 테스트 하기 때문에 

오류가 나면 어디서 났는지 파악하고 수정하기가 어렵다.

 

TDD

TDD 개발 방식은 다음과 같다.

유저 요구 사항 분석 => 기능 설계 => 테스트 코드 작성 => 코드 개발 => 리팩토링

 

테스트 케이스를 먼저 만들어야 하기 때문에 설계 단계에서 프로그램의 목적이 명확하게 정의된다.

테스트 코드를 만들면서 수정 사항이 발생하면 테스트 케이스에 수정사항을 추가하고 설계를 수정한다.

그 다음 코드를 개발해서 테스트를 통과한 코드만 사용한다. 

 

테스트 코드를 만들면서 설계가 자연스럽게 수정되므로 

설계 수정 후 코드 수정 후 테스트를 하는 것보다 효율적으로 일을 할 수 있다.

 

장점

 

객체 지향적으로 개발할 수 있음 

TDD에서는 재사용 가능한 코드를 만드는 것이 목적이다.

한 함수는 하나의 일만 담당하고, 이런 함수를 레고 블럭처럼 조립해서 프로그램을 만든다.

 

설계 수정 시간 단축

테스트 코드를 먼저 작성하면 실제 코드의 기능을 더 명확하게 이해할 수 있다.

그렇기 때문에 코드 설계에 문제가 있으면 빠르게 찾아내고 수정할 수 있다.

 

코드 유지보수가 쉬움

TDD에서는 최소 단위(함수, 클래스) 기반의 테스트를 작성한다.

따라서 모든 모듈을 합쳤을 때 문제가 생기더라도 테스트를 해보면 어느 모듈이 문제인지 바로 알아낼 수 있다. 

 

테스트 코드가 테스트 문서 역할을 할 수 있음

일반적인 개발 방식에서는 통합 테스트만 하기 때문에 무엇을 테스트했는지 알려주는 문서가 추가로 필요하다.

TDD에서는 unit test를 진행하므로 정확히 어떤 함수에 어떤 테스트를 진행했는지 테스트 코드만으로도 알 수 있다.

 

단점

긴 준비기간

TDD를 사용하려면 개발 환경이 구축되어 있어야 하고, 개발자도 준비가 되어 있어야 한다.

개발자 교육에 1 ~ 6개월 정도가 소모될 수 있다.

 

생산성이 오히려 저하될 수 있음

어떤 예외가 발생할 지 뻔한 경우에도 테스트 코드를 작성하고 시작해야 한다.

또 테스트 코드를 작성하는 데도 시간과 비용이 들기 때문에 

테스트 코드 작성에 지나치게 몰입하면 전반적인 생산성이 떨어질 수 있다.

 

 

참고

Dev: TDD, 테스트 주도 개발의 기초와 예시

인코덤 - 테스트 주도 개발

TDD란? 테스트 주도 개발