TDD란

TDD(Test-Driven Development, 테스트 주도 개발)는 소프트웨어 개발 방법론 중 하나로, 매우 짧은 개발 사이클의 반복에 의존하는 개발 프로세스.
이 방법론의 핵심은 실제 코드를 작성하기 전에 테스트 케이스를 먼저 작성하는것.

1. 실패하는 테스트 작성(Red)
2. 테스트를 통과하는 코드작성(Green)
3. 코드 리팩토링(Refactor)
   이 세단계를 빠르게 반복하면서 개발진행

1. 실패하는 테스트 작성

//TextField.tsx
export default function TextField() {
	return <input type='text' />;
}

//TextField.test.tsx

it('기본 placeholder "텍스트를 입력해 주세요."가 노출된다.', async () => {
	await render(<TextField />);
	const textInput = screen.getByPlaceholderText('텍스트를 입력해 주세요.');
	expect(textInput).toBeInTheDocument();
});

placeholder 값이 없기 때문에 테스트 실패

2. 테스트를 통과하는 코드작성

//TextField.test.tsx
export default function TextField() {
	return <input type='text' placeholder='텍스트를 입력해 주세요.' />;
}

3. 리팩토링
위의 컴포넌트에서는 리팩토링할거리가 없지만 복잡한 컴포넌트의 경우 테스트로 작성된 원칙을 위배하지 않으면서 코드 수정이 가능해진다.

TDD의 장단점

장점

• 버그감소
  테스트 케이스를 먼저 작성하기떄문에 개발초기부터 버그를 발견하고 수정가능.
• 설계 품질 향상
  TDD는 코드를 작성하기 전에 설계를 철저히 고민하게 만듦. 이는 유지보수가 용이하고 확장성 있는 코드를 만드는데 기여
• 리팩토링 용이
  이미 테스트케이스가 작성되어 있기 때문에 코드를 리팩토링할때 안정성을 유지하면서 개선가능

단점

• 학습곡선
  TDD를 효과적으로 사용하기 위해서는 테스트 케이스 작성에대한 이해와 경험 필요. 러닝커브가 있을 수 있음.
• 개발 시간 증가
  테스트 케이스를 먼저 작성하고 이를 통과하기 위한 코드를 개발하는 과정은 초기 개발 속도를 늦출 수 있음
• 과도한 설계
  때로는 TDD가 과도한 설계를 유도할 수 있음. 모든 작은 기능에 대해 테스트를 작성하다보면 필요 이상으로 복잡한 코드나 구조가 만들어질 수 있음
• 모든 상황에 적합하지 않음
  일부 프로젝트나 기능에서는 TDD가 불필요하거나 비효율적일 수 있음. 매우 단순한 코드나 빠르게 변하는 요구사항을 가진 프로젝트에서는 적용하기 힘들 수 있음

BDD

BDD는 행동주도 개발이라 불리는 TDD에서 파생된 소프트웨어 개발 방법론중 하나. 소프트웨어 개발과 관련된 모든 사람들이 이해할수 있는 명확한 이해와 커뮤니케이션을 통해 개발의 효율성과 품질을 높이는것을 목표로함

BDD는 기술적인 관점보다는 비지니스 요구사항에 초점을 맞추며, 소프트웨어가 어떻게 행동해야하는지에 대한 시나리오를 작성하여 개발

• BDD는 시스템의 행동을 중심으로 개발진행. 행동=> 사용자가 시스템과 상호작용하는 방식과 시스템이 그에 대해 반응하는 방식
• BDD는 개발자, 테스터, 비지니스 애널리스트등 프로젝트에 관련된 모든 이해관계자가 명확하게 이해할 수 있는 언어로 시나라오를 작성.
  -> 이를통해 모두가 통일한 목표를 향해 나아갈수 있도록 함
  -> 이를 유비쿼터스 언어, 보편언어라함
• BDD는 구체적인 예제를 통해 요구사항을 명확히함. 이러한 예제는 사양과 테스트 케이스로 사용되며 개발과정에서 중요한 참조 지점이 됨.

// Calc.spec.js 
// 파일이름을 Calc.test.js 대신 Calc.spec.js 로 짓습니다.

 describe('Calc', () => { 
 // 사용자 시나리오 중심으로 작성합니다. 
 it('첫번째 인자와 두번째 인자의 합 연산을 합니다.', () => { 
 // given / when / then 을 명확히 합니다. 
 const useCases = [ { arg: [1, 2] } ]; 
 const results = [3]; 
 for (let i = 0; i < useCases.length; i++) { 
	 const useCase = useCases[i]; 
	 const result = Calc().sum(...useCase.arg); 
	 // 사용자 중심의 인터페이스로 assertion을 진행할 수 있습니다.
	 expect(result).to.equal(results[i]); 
	 } 
	}); 
	... 
});

spect js vs test js
둘다 기능상으론 동일함. spec의 경우 BDD스타일에서 많이 사용되며, 이 컴포넌트가 이렇게 동작해야 한다에 초첨. TDD에서는 이 코드가 통과하는지 테스트할다에 초점

TDD는 모든 프런트엔드 테스트 방법에 적용할 수 있을까?

	검증 범위	도입 시점	실행 시간	TDD 적용
단위 테스트	독립적인 모듈 단위	개발 단계	매우 짧음	가능
통합 테스트	일부 모듈이 조합 되었을 때의 비즈니스 로직	개발 단계	짧음 또는 보통	가능
시각적 회귀 테스트	컴포넌트의 UI	개발 및 기능 검증이 완료된 상태	매우 오래 걸림	불가능
E2E 테스트	앱의 전반적인 워크 플로우	개발 완료 상태(QA 직전 상태)	매우 오래 걸림	불가능