본문 바로가기

일하랴 공부하랴/ETC

TDD (Test Driven Development :: 테스트 주도 개발)

개발 기법의 하나로 개발을 진행하기에 앞서 테스트 코드를 먼저 만들어 놓고 해당 테스트 코드를 만족하는 업무코드를 작성하는 식으로 진행한다. 결과적으로 테스트가 개발을 이끌어가는 방식이 되기 때문에 Test Driven Development(TDD)라고 불린다.

 

TDD의 3가지 절차

TDD Cycle in Unit Test(출처: http://memee.github.io/tdd/#/7 , TDD 관련 발표 자료)

1. 실패

   첫번째 절차는 실패이다. 실패하는 테스트 케이스를 먼저 말들라는 것이다. 실패하는 테스트 케이스를 만들 때는 프로젝트의 전체 기능에 대하여 처음부터 모든 테스트케이스를 작성하는 것이 아니라, 지금 가장 먼저 구현할 기능 하나씩 테스트 케이스를 작성한다

2. 성공

  두번째는 성공이다. 우리가 작성하는 위의 실패하는 테스트 케이스를 통과시키기 위해 코드를 작성하여 테스트를 통과하는 것이다.

 

3. 리팩토링

  세번째는 리팩토링이다. 우리가 구현한 코드에 중복되는 코드가 있거나, 혹은 더 개선시킬 방법이 있다면 리팩토링을 진행한다. 리팩토링을 진행하고 나서도 테스트 케이스가 성공하는지 확인 하고, 다시 첫번째로 돌아가서 다음 기능 구현을 위한 새로운 실패하는 테스트 케이스를 작성하는 것이다.

 

Test-Driven Deelopment 프로세스

 

TDD의 3가지 Rules

1. 실패하는 테스트를 작성하기 전에는 제품 코드를 작성하지 않는다.
You are not allowed write any prodection code unless it is to make a failing unit test pass

2. 실패하는 테스트 코드를 한번에 하나 이상 작성하지 않는다. (컴파일 에러도 실패다)
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are faileres.

3. 현재 실패한 테스트 코드를 성공시키는데 충분한 정도로만 제품 코드를 작성한다.
You are not allowed to write any more prodection code than is sufficient to pass the one failing unit test.

 

TDD의 장점

1. 객체지향적인 코드 개발

2. 설계 수정 시간의 단축

3. 디버깅 기간의 단축

4. 유지 보수의 용이성

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

 

 

TDD를 한다는것은 단순히 테스트 코드를 먼저 작성하는 것이 아니라
1. Refactoring을 통해 Clean Code를 유지하려고 노력하는것.
2. Simple design으로 시작해서 점진적으로 설계 개발하겠다는 것.
3. 작은 기능이라도 사용자에게 가치있는 제품을 자주 전달하겠다는 것.
:: 결국 얻고자 하는 건, 좋은 설계 / 좋은 제품

'일하랴 공부하랴 > ETC' 카테고리의 다른 글

TDD - JUnit assert(단언)  (0) 2020.08.03