TDD

TDD ; Test-Driven Development

= 테스트 먼저 짠다

 

매우 짧은 개발 사이클을 반복하는 것에 기반한 소프트웨어 개발 프로세스

 - 요구사항(Requirements)이 매우 구체적인 테스트 케이스가 된다.

- 그래서 코드가 개선되면 테스트를 pass하게 된다.

 

 

TDD 사이클

1. 테스트를 추가한다.

2. 모든 테스트를 Run하고 새 test가 fail하는지 본다.

3. 코드를 작성한다.

4. 모든 테스트를 Run한다.

5. 코드를 Refactoring 한다.

 

- 함수마다 테스트코드를 작성하게 된다.

- 테스트가 하나 추가될 때마다 전체 코드를 한번 더 테스트해야 한다.

 

* Test Coverage

: 내 코드에 테스트를 Run했을 때 성공한 퍼센트(%)

 

* Test Lag

: 테스트 코드가 procedure 코드보다 뒤처질 때를 의미한다.

 

 

TDD의 세 가지 규칙(Law)

1. unit test가 실패한 프로덕션 코드를 개선하기 위해 코드를 짜는 것이 아니라면 프로덕션 코드를 짜선 안된다.

2. test를 미리 많이 만들어 놓지 않는다.

3. test가 통과되는 부분까지의 production code를 짜라.

 

 

좋은 Test를 짜는 게 중요하다.

bade test code는 수행이 오래 걸리고, 의미 없는 test code는 오히려 해악을 끼친다. 

 

TDD의 장점

소프트웨어 디자인이 모듈화된다.

- unit test가 통과되기 전까지 다음 단계로 개발을 진행하지 않으므로 한 번에 하나의 기능에 집중할 수 있다. 

버그 발견이 용이해지고, 코드 재사용성이 높아진다.

 

코드 유지보수가 쉬워진다.

- 작은 단위로 코드가 쪼개지므로 개발자들의 수고가 덜어지고 테스트 요구 사항을 준수하기 쉬워진다. 

 

코드 리팩터링이 더 쉬워진다.

- 코드가 다뤄지기 쉬워지고, 테스트와 유지보수 시간을 감소시킨다. 

 

비용 감소

- 유지보수와 버그 fix에 시간과 노력이 덜 든다.

 

TDD로 코드를 더 잘 문서화 가능하다.

- 문서를 만들 필요가 없다. Unit Test에 사용된 테스트들이 이 코드들이 어떻게 작동되는지에 대한 일종의 문서화 역할을 한다.

 

디버깅 시간이 줄어든다.

버그와 에러가 줄어들기 때문이다.

 

 

 

TDD의 단점

개발 프로세스 시간이 증가한다.

- 제품 출시 기간이 얼마 남지 않은 경우에는 적합하지 않다. 테스트를 작성하느라 프로덕션 코드를 작성할 시간이 없는 상황이 발생하기 때문이다.

 

TDD 접근 방식을 배우기 어렵다.

- TDD 방식을 한번도 도입해 본적 없는 팀이 사용하게 된다면 헤맬 수도 있다.

 

"All or Noting" 방식

- 개발자가 한 번에 한 가지에 집중하는 방식이기 때문에 코드 플랜에 영향을 줄수도 있다.

 

유지보수가 어렵다.

- 제품의 요구사항이 바뀌면, 테스트도 바뀌어야 한다. 그러면 새로운 테스트에 맞춘 새로운 코드를 다시 작성해야 한다.

 

 

 

 

 

- 참고 자료 -

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

ArticleS.UncleBob.TheThreeRulesOfTdd

https://fortegrp.com/test-driven-development-benefits/

How test-driven development help business: benefits of TDD | Forte Group