TDD란?

테스트 주도 개발이라 부르는 방법론

실제로 개발 코드를 작성하기 전에 소프트웨어의 요구사항을 테스트 케이스로 먼저 작성한 후 기능을 추가하고 리팩토링하는 과정을 테스트로 반복 검증하며 개발하는 방법론이다.

TDD의 사이클

TDD는 테스트 실패, 테스트 성공, 리팩토링 총 3개가 사이클로 이루어져있다.

• 테스트 실패 : 소프트웨어 요구사항에 대한 테스트 작성. 여기서 중요한 것은 실제 로직이 개발되기 전에 명확하고 구체적인 하나의 기능에 대해 먼저 테스트를 작성하는 것이다. (기능보다 테스트를 먼저 작성함으로써 개발 초기부터 앱의 요구사항을 깊게 이해할 수 있다.) 이때 주의할 점은, 테스트 코드 자체의 문제로 테스트가 실패해버리면 안된다는 것이다. 만약 테스트 코드 자체의 문제로 테스트가 실패한다면 신뢰성이 굉장히 떨어지기 때문이다.

// 1. 테스트 작성 (테스트 실패)
it('기본 placeholder "텍스트를 입력해 주세요."가 노출된다.', async () => {
	await render(<TextField />);

	const textInput = screen.getByPlaceholderText('텍스트를 입력해 주세요.');

	expect(textInput).toBeInTheDocument();
})

• 테스트 성공 : 추가한 기능의 실제 코드를 구현하여 테스트가 성공하는 단계. 기존에 작성한 테스트 코드는 반드시 통과해야 하며 추가된 기능에 대해서만 코드를 수정해야 한다. 테스트 대상이 되는 기능 외에 다른 코드를 작성하는 하지 않는 것이 원칙이다.

// 2. 테스트에 해당하는 코드 작성 (테스트 성공)
export deafult function TextField() {
	return <input type="text" placeholder="텍스트를 입력해 주세요." />;
}

• 리팩토링 : 테스트를 모두 통과한 상태에서 코드를 리팩토링 하는 과정. 가독성이나 성능에 관련된 개선이나 컴포넌트끼리의 강한 결합도를 분리하거나 재사용성을 높이는 등 코드 퀄리티나 유지 보수 향상을 위한 작업을을 한다.

TDD의 장단점

TDD는 테스트를 기반으로 모든 개발을 수행하기 때문에 TDD를 도입하면 테스트를 작성함으로써 얻을 수 있는 장점을 누릴 수 있다.

TDD를 도입하면 많은 장점이 존재하지만 테스트 코드 작성 비용이 있기 때문에 당장의 생산성은 줄어든다. 하지만 초기 비용이 많이 들더라도 안정적으로 코드를 작성할 수 있기 때문에 장기적으로 봤을 때 효율적이다.

TDD를 언제 도입해야 할까

• 잠깐 오픈하고 금방 사라질 프로젝트에는 도입하기 힘들다
• 일정이 너무 빡빡한 프로젝트에는 도입하기 힘들다
• 간단한 UI만 보여주거나 특별한 기능이 없는 앱은 도입하지 않는 것이 좋다
• 단위 테스트의 대상이 되는 공통 컴포넌트나 훅에 적용하면 좋다

결론

TDD 방법론을 절대적으로 맹신하며 지켜야 한다는 것이 아니다.

중요한 것은 개발 단계에서 테스트 피드백을 통해 기능의 안정성을 높이는 것이므로 상황에 맞게 유연하게 테스트를 작성하면서 테스트 자체의 목적을 잊지 않아야 한다.