[TDD] TDD(Test-Driven-Development)란?

TDD 란?

Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다.

 

TDD는 설계 이후 코드 개발 및 테스트케이스를 작성하는 기존의 개발 프로세스와는 다르게 테스트 케이스를 작성한 후 실제 코드를 개발하여 리팩터링 하는 절차를 따른다.

 

기존 프로세스

디자인 -> 코드개발 -> 테스트 [ -> 설계(디자인 수정) ]

 

TDD 프로세스

디자인 -> 테스트 코드 작성 [ -> 설계(디자인 수정 ] -> 코드개발 -> 리팩토링

---

TDD 개발 주기

 

RED 단계에서는 실패하는 테스트 코드를 작성한다.

GREEN 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.

BLUE 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다. 

 

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 이를 통해서 실제 코드에 대해 기대되는 바를 명확하게 정의 함으로써 불필요한 설계를 피할 수 있고 정확한 요구사항에 집중할 수 있다.

---

TDD는 왜 해야 할까?

TDD의 장점

디버깅 시간 단축

모듈 별로 테스트를 자동화를 하지 않는다면 에러가 생겼을 경우 모든 레벨의 코드를 살펴보아야 한다.

하지만, TDD의 경우 자동화된 단위 테스트를 통해 특정 버그를 쉽게 찾을 수 있다.

 

높은 코드의 안정성

짧은 주기의 테스트 코드 개발-리팩토링 단계를 거치며 끊임없이 보완하고 철저한 모듈화를 통해 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하여 코드의 안정성을 높일 수 있다.

 

재설계 시간 단축

테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야 하는지 분명히 정의하고 개발을 시작하게 되고, 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해 볼 수 있다.

이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.

 

하지만, 이러한 장점에도 불구하고 TDD를 쉽게 도입하지 못하는 단점도 있다.

TDD의 단점

생산성 저하

처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 한다. 때문에 개발 시간도 늘어난다.

또한, 단순 개발이나 단발성 프로젝트의 경우 개발기간이 짧아 TDD를 적용하게 되었을 때 복사, 붙여 넣기를 통한 뻔한 중복 테스트 코드를 작성하게 되면 비효율적일 수 있다. 

SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.

---

참고 자료

- https://inpa.tistory.com/entry/QA-%F0%9F%93%9A-TDD-%EB%B0%A9%EB%B2%95%EB%A1%A0-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C

- https://velog.io/@wngud4950/TDD%EB%9E%80

- https://hanamon.kr/tdd%EB%9E%80-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A3%BC%EB%8F%84-%EA%B0%9C%EB%B0%9C/

- http://clipsoft.co.kr/wp/blog/tddtest-driven-development-%EB%B0%A9%EB%B2%95%EB%A1%A0/