이 글은 Computer Science에 관한 앎의 지평을 넓히기 위해
초보자를 위한 면접 질문 깃허브를 보며 공부한 내용을 정리한 것입니다.
TDD (Test-Driven Development)
테스트 기반 개발.
기존의 개발 방법과 달리, 테스트 코드 작성이 실제 코드 작성에 선행한다.
절차를 살펴보면:
요구되는 기능에 대해 자동화된 테스트케이스 작성 → 테스트를 통과하는 가장 간단한 코드 작성 → 상황에 맞춰 리팩토링
이 반복된다. 즉, 테스트 기반 개발은 위와 같이 매우 짧은 개발 주기가 여러 번 반복된다는 특성을 지닌다.
활용 상황
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% 무결성을 주장하지 않았다. 즉, 모든 부분에 대한 테스트 코드를 작성할 수 없으며, 테스트 코드가 버그를 완전히 예방해주는 것도 아니다.
참고
'Computer Science > 개발상식' 카테고리의 다른 글
| RESTful API (0) | 2022.03.17 |
|---|---|
| 객체지향 프로그래밍 (OOP) (0) | 2022.03.15 |