[개발 패턴] TDD

TEST DRIVE DEVELOPMENT

테스트 주도 개발에 대한 많은 이야기를 들었었다. 쓰레기라느니 좋다느니.. 등등 나는 실제로 와닿지는 않았는데 우아한테크코스를 경험하면서 필요성을 느꼈다.

내가 느낀 필요성은 프로덕션 코드를 작성하고 테스트 코드를 작성하면 테스트하기 너무 힘든 메소드 같은 것들이 생길 때 필요하다고 느꼈다. 먼저 테스트 코드를 짜고 프로덕션을 맞춘다면 충분히 좋게 테스트코드를 짤 수 있다고 생각했다.

---

TDD란 Test First Development + 리팩토링을 의미한다.

TEST -> FEAT -> REFACTOR 가 반복된다고 생각한다.

 

TDD 하는 이유

• 디버깅 시간을 줄여준다.
• 동작하는 문서 역할을 한다.
• 변화에 대한 두려움을 줄여준다.

TDD 원칙

1. 실패하는 단위 테스트를 작성할 때 까지 프로덕션 코드를 작성하지 않는다.

2. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위테스트를 작성한다.

3. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다.

---

TDD 리팩토링 적용 효과

서비스 안정성이 높아진다.

• 버그 발생 가능성이 줄어든다.
• 코드 품질이 높아져 변화에 좀 더 빠르게 대응 가능

개발자들의 역량 강화

• 학습 효율이 높아져 개발자의 역량을 높일 수 있다
• 개발자의 만족도가 높아져 이직율이 낮아진다.

---