TDD : Test-Driven Development

클라이언트와 백엔드에서의 TDD 적용 및 개발 철학

클라이언트 개발에서의 TDD

• UI 변경이 잦아 TDD 적용이 비효율적일 수 있음.

  FE에서 테스트는 우리가 예상한 결과값이 나오는 것들을 테스트 코드로 만드는데
  UI가 계속 변경되고 있는 와중에 테스트 코드를 짜게 되면 할 일이 더 많아짐

• 시나리오 테스트(e.g., Playwright, Cypress, Puppeteer) 활용이 적절.
• 퍼포먼스 테스트는 UI가 고정된 상태에서 최적화 목적으로 활용 가능.

백엔드 개발에서의 TDD

• 입력과 출력이 예측 가능하여 TDD 적용이 적합.
• API 개발 시 수동 테스트를 줄이고 자동화 가능.
• 로컬 테스트 데이터베이스 구축이 중요.

프론트엔드 TDD 적용 방식

• 프론트엔드는 변경이 잦아 백엔드와 다른 성향을 가짐.
• 변경점이 많아 시나리오 기반 테스트가 적합.
• 실행 시간을 최적화하고 로직 성능을 개선하는 데 활용.
• 퍼포먼스 최적화가 필요한 경우 공격적으로 TDD 적용 가능.
• 최종 성능 개선을 위해 마지막 단계에서 활용.
• 전제 조건: UI가 완성되고 메인 플로우가 변경되지 않아야 함.

테스트 기반 개발 원칙

✅ 프론트엔드

• 완성도를 높이는 마지막 단계에서 성능 최적화.
• 시나리오 기반 테스트 활용.
• 컴포넌트보다 함수 단위 테스트가 현실적.

✅ 백엔드

• 초기 개발 단계부터 TDD 적용.
• API 자동화 테스트로 비효율 제거.
• 로컬 환경에서 테스트 데이터베이스 활용.

TDD 시작 방법

📌 백엔드

1. 공식 문서 참고 (NestJS, Django, Spring 등).
2. AI 툴 활용하여 테스트 코드 완성도 향상.
3. 지속적인 테스트 코드 수정 및 최적화.

📌 프론트엔드

• 유닛 테스트(Jest, Vitest) → 함수 로직 검증.
• 시나리오 테스트(Cypress, Playwright) → 동작 흐름 검증.
• E2E 테스트 → 전체 서비스 흐름 검증.
• 컴포넌트 테스트(Storybook)는 유지 부담이 큼, 함수 중심 테스트가 효율적.

컴포넌트 vs 함수 테스트

• 컴포넌트 테스트: 변경이 많아 유지 비용이 큼.
• 함수 테스트: 예측 가능한 입력/출력으로 유지보수가 쉬움.