TDD (Test-driven development)

이 글은 Computer Science에 관한 앎의 지평을 넓히기 위해

초보자를 위한 면접 질문 깃허브를 보며 공부한 내용을 정리한 것입니다.

---

TDD (Test-Driven Development)

https://ko.wikipedia.org/wiki/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C

테스트 기반 개발.

기존의 개발 방법과 달리, 테스트 코드 작성이 실제 코드 작성에 선행한다.

절차를 살펴보면:

요구되는 기능에 대해 자동화된 테스트케이스 작성 → 테스트를 통과하는 가장 간단한 코드 작성 → 상황에 맞춰 리팩토링

이 반복된다. 즉, 테스트 기반 개발은 위와 같이 매우 짧은 개발 주기가 여러 번 반복된다는 특성을 지닌다.

 

활용 상황

1) 개발자 스스로의 불확실성이 높은 경우: 처음 해보는 프로젝트 주제

2) 외부의 불확실성이 높은 경우: 고객의 요구조건이 가변적인 프로젝트

3) 개발하는 과정에서 코드를 많이 변경해야 한다고 생각하는 경우

4) 코드를 개발하는 사람과 유지보수하는 사람이 다를 가능성이 높을 때

 

장점

1) 사용자 요구사항에 대한 깊은 이해: 테스트 케이스는 사용자의 요구사항과 명세를 바탕으로 만들어진다. 고로, 테스트에 기반한 TDD 프로세스는 개발자로 하여금 요구사항과 명세의 내용을 명확하게 이해하고 이에 집중하도록 만드는 효과가 있다.

2) 빠른 디버깅: 새로운 기능을 추가할 때마다 테스트를 시행해 기존 기능의 정상작동 여부를 확인하므로 코드 추가로 인한 기능의 오작동을 빠르게 확인하고 고칠 수 있다.

3) 빠른 재설계: 코드 리팩토링 시에 빈번한 테스팅을 통해 양질의 리팩토링을 빠르게 진행할 수 있다.

4) 협력의 증진: 공유가능한 테스트를 통해 다른 사람의 코드에 쉽게 접근이 가능해지며 이해가 빨라진다.

5) 객체 지향적인 코드 생산: TDD는 코드의 재사용성을 명시하므로 기능별 모듈화가 이뤄진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어의 개발을 가능하게 한다.

 

단점

1) 생산성의 저하: 개발기간이 짧을 경우 테스트 케이스까지 작성하는 것은 힘겨울 수 있다. 코드량의 증가가 내포된 개발 프로세스이므로, 빠른 생산성이 요구되는 일에는 적합하지 않을 수 있다. (일반적인 개발방식에 비해 소요시간이 약 10~30% 증가한다고 한다.)

2) 테스트 코드 작성이 쉽지 않다. Which part, how, and with what? 

 

유의

TDD 는 100% coverage 와 100% 무결성을 주장하지 않았다. 즉, 모든 부분에 대한 테스트 코드를 작성할 수 없으며, 테스트 코드가 버그를 완전히 예방해주는 것도 아니다.

---

참고

• TDD(Test-Driven-Development) 방법론