TDD(Test Driven Development)

정의

"프로그램을 작성하기 전에 테스트를 먼저 작성하는 것"

==> "업무 코드를 작성하기 전에 테스트 코드를 먼저 만드는 것!"

[일반적인 개발 프로세스]

단점 : 테스트를 통해서 원하는 결과가 나오지 않았을 때 처음 소프트웨어 디자인을 다시 수정해야 될 수도 있음.

[TDD 프로세스]

TDD의 경우 테스트 코드를 작성한 뒤에 코드를 작성.

==> 보다 정확한 프로그래밍 목적을 디자인 단계에서 반드시 미리 정의해야만 하고 또 무엇을 테스트해야 할 지 미리 정의해야함.

장점

1. 보다 튼튼한 객체지향적인 코드 생산 가능

 - 테스트 코드를 먼저 작성함으로써 하나하나의 기능들에 대해서 철저히 구조화 시켜 코드를 작성하므로써 나도 모르게 디자인 패턴들을 하나하나 적용하고 인터페이스들을 이용해서 느슨한 결합을 실현시키는 자신을 발견하게됨

==> 왜냐하면, TDD가 코드의 재사용성을 보장해야만 가능하기 때문.

2. 재설계 시간의 단축

 - 테스트 코드를 먼저 작성하기 때문에 내가 지금 무엇을 해야 하는지 분명히 정의를 하고 시작하게 됨.

3. 디버깅 시간의 단축

 - 버그 발생시, 모든 레이어들을 전부다 디버깅할 필요 없이 자동화 된 유닛테스팅 결과로 우리는 손 쉽게 찾아 낼 수 있다.

4. 애자일과의 시너지 효과

 - 정확히 말하면 BDD(Behavior-Driven Development)를 적용하는데 있어서 큰 시너지 효과.

5. 테스트 문서의 대체가능

 - 테스팅을 자동화 시킴으로 동시에 보다 정확한 테스트 근거를 산출할 수 있다.

6. 추가 구현의 용이함

 - 유닛 테스트로 자동화 될 경우에 우리는 수동으로 모든 테스트를 다시 진행해야 되는 시간적인 낭비를 줄일 수 있다.

단점

1. 시간이 걸린다.

 - TDD공부 및 추가적으로 테스트 코드를 작성해야 하기 때문

2. '납기일'이라는 데드라인.

 - 갑 을 병 정 내려가는 프로젝트일수록 퀄리티 보다는 개발기간과 타이밍이 중요.

3. 테스트가 어려운 예외가 생길 수 있음

 - 예외 상황시, 꼼수가 있긴 하지만 그 꼼수를 위해 구조를 바꾸자니 이건 아무래도 아닌 것 같고, 테스트는 말 그대로 테스트일뿐 실제 코드가 더 중요한 상황인데도 불구하고 테스트 원칙 대문에 쉽게 넘어가지 못하는 경우