TDD Tip

출처 : 테스트주도개발 TDD 실천법과 도구

TDD유의사항

테스트케이스는 이름이 중요하다.
더 이상 제대로 동작하지 않은 테스트 케이스는 제거한다.
TDD는 자동화된 테스트를 만드는 것이 최종 목표가 아니다.
모든 상황에 대한 테스트 케이스를 만들 필요는 없다
여러 개의 실패하는 테스트 케이스를 한 번에 만들지 않는다.
하나의 테스트 케이스는 하나만 테스트하도록 작성한다.
전통적인 테스트 기법을 배워둔다.
테스트 케이스는 최대한 고립시킨다.

TIP

1. 기능 테스트, 단위 테스트 구분

기능 테스트 - 사용자 관점의 테스트
단위 테스트 - 애플리케이션 관점의 테스트

기능 테스트는 외부 동작 위주로 진행되기 때문에 블랙박스 테스트로 볼수 있다. 하지만 일부 단위가 수정 되었을 때 오류가 발생되게 되면 해당 오류 단위를 추적하기 힘든 상황이 있다. 이럴 경우 단위 테스트가 잘 구성되어있다면 쉽게 오류난 부분을 찾는데 도움이 될 것이다.

2. 미리 예상할 수 없는 경우 TDD진행

임의의 값을 만들어 실패를 만들고 실패 때 나온 값을 결과값으로 현재 상태가 올바름을 알 수밖에 없다.  TDD는 사실 개발자가 특정 메소드를 호출했을 때 어떤 값이 리턴될지 알고 있다는 것을 사전조건으로 가정되어 있다.

3. 테스트 케이스 코드를 작성하기 어려울 때

코드가 불필요한 클래스와 의존관계가 있는지 확인한다. 의존성을 피할수 없는 경우 Mock객체를 사용하는 방법이 있지만 최솨한만 사용한다. 억지로 테스트를 작성하는 것은 잘못된 접근이다.

4. 테스트 케이스를 작성할 때 외부 모듈이 익숙지 않을 경우

위 경우 테스트 케이스 작성은 두가지로 나눌수 있다.

가. 라이브러리 학습을 위한 테스트 케이스 - 신뢰도 측정의 개념으로 테스트 케이스를 작성한다.
나. 업무 코드 작성을 위한 테스트 케이스 - 외부 모듈의 API를 배제하고 업무시나리오에 맞게 테스트 케이스를 작성한다. API는 재료로 사용하는 것이라는 생각으로 시나리오 베이스 테스트 케이스를 작성하면 수월하다

5. 수동 테스트 VS 자동화된 테스트

자동화는 지향해야하는 목표이다. 하지만 자동화하는데 많은 노력이 들어간다. 따라서 프로젝트 적당한 시기에 도입한다. 수동 테스트의 단점은 회귀 테스트가 부담이 될 것이다. 기능이 추가/변경 될 때마다 기능 테스트를 수행해야하는데 누락되거나 지나치게 단순화된 형태로 테스트를 진행하게 될 가능성이 커진다.

6. void 메소드를 테스트 할 경우

메소드를 아래와 같이 나눌 수 있다

리턴값이 있는 메소드 : 기능
void 메소드 : 절차

메소드의 리턴값이 없다는 의미는 로직의 절차를 기술했거나, 로직 트리의 맨 끝에 해당하는 기능 위임 작업을 목표로 하는 것을 의미한다. 이 경우 행위 기반 테스트를 해야한다. 가장 간단한 방법은 상태를 확인 할수 있는 다른 메소드로 결과를 테스트 하는 것이다. (isClicked, isReady 등)