Svelte 시니어 테스트 · 코드품질 기술면접

@testing-library/svelte는 사용자 중심 테스트를 지향하므로 render 후 screen 쿼리로 DOM 요소를 찾고 userEvent로 상호작용을 시뮬레이션합니다. reactive statement는 의존하는 값을 변경한 후 await tick()을 호출해 반응성 업데이트를 기다립니다. store는 테스트용 mock store를 만들거나 writable store를 직접 주입해 set/update 메서드로 값을 변경하고 결과를 검증합니다. 컴포넌트 props 변경 시에는 component.$set()을 사용하고, 내부 상태 변경은 사용자 이벤트를 통해 간접적으로 테스트합니다. 비동기 업데이트는 waitFor나 findBy 쿼리를 활용해 DOM 변경을 기다립니다.

비즈니스 로직은 Svelte 컴포넌트에서 분리해 순수 TypeScript 함수나 클래스로 작성하고, 이 부분에 대해 먼저 TDD를 적용합니다. 컴포넌트 레벨에서는 Outside-In TDD 방식으로 사용자 시나리오를 먼저 테스트 코드로 작성한 후 구현합니다. store 로직도 컴포넌트와 분리해 독립적으로 테스트 가능하게 만듭니다. 초기에는 Svelte의 컴파일 특성과 반응성 시스템 때문에 테스트 설정이 복잡했으나, Vite 기반 테스트 환경과 svelte-preprocess를 활용해 해결했습니다. 팀원들의 TDD 경험 부족은 페어 프로그래밍과 코드 리뷰를 통해 점진적으로 개선했으며, 핵심 비즈니스 로직부터 단계적으로 TDD를 확대했습니다.

통합 테스트에서는 MSW를 사용해 네트워크 레벨에서 API를 모킹하므로 실제 HTTP 요청 코드는 그대로 사용하면서 응답만 제어합니다. 테스트 시나리오는 실제 사용자 여정을 따라 작성하며, 여러 컴포넌트가 함께 렌더링되고 상호작용하는 상황을 검증합니다. store를 통한 전역 상태 공유도 실제 구현을 사용해 컴포넌트 간 데이터 흐름을 테스트합니다. 각 테스트마다 beforeEach에서 store를 초기화하고 MSW 핸들러를 설정해 격리된 환경을 보장합니다. 성공/실패/로딩 상태 등 다양한 시나리오를 MSW 핸들러로 쉽게 재현할 수 있으며, 네트워크 지연도 시뮬레이션해 실제 환경을 근접하게 테스트합니다.

Svelte 코드 리뷰에서는 반응성 시스템의 올바른 사용, 불필요한 재렌더링 방지, store 사용의 적절성, 컴포넌트 크기와 책임 분리를 중점적으로 확인합니다. 주니어 개발자 코드는 교육적 관점에서 접근해 왜 그렇게 작성했는지 먼저 질문하고, 더 나은 방법을 제시할 때는 이유와 함께 설명하며 학습 자료를 공유합니다. 동료 시니어의 코드는 아키텍처 관점의 트레이드오프, 확장성, 유지보수성에 집중하며 대안을 제시할 때는 근거와 함께 토론 형식으로 진행합니다. 모든 리뷰에서 긍정적인 부분을 먼저 언급하고, 비판보다는 제안 형식으로 피드백하며, 자동화 가능한 부분은 린터나 포매터 설정으로 해결해 본질적인 로직에 집중합니다.

테스트 코드가 없다면 먼저 현재 동작을 보존하는 특성화 테스트(Characterization Test)를 작성해 안전망을 구축합니다. 가장 중요하고 자주 변경되는 부분부터 우선순위를 정해 점진적으로 리팩토링하며, 한 번에 하나의 변경만 수행합니다. 비즈니스 로직을 컴포넌트에서 분리해 순수 함수로 추출하는 것부터 시작하면 테스트 작성이 쉬워집니다. 큰 컴포넌트는 작은 단위로 분리하고, 각 단계마다 테스트를 추가하며 기능이 동일하게 동작하는지 확인합니다. TypeScript를 도입해 타입 안정성을 확보하고, 린터와 포매터로 코드 스타일을 통일합니다. 리팩토링 중에는 기능 추가를 동시에 하지 않으며, 각 단계를 작은 커밋으로 나눠 문제 발생 시 쉽게 롤백할 수 있게 합니다.

테스트 커버리지는 테스트되지 않은 코드를 찾는 도구로 활용하지만, 높은 커버리지가 곧 좋은 테스트를 의미하지는 않습니다. 100% 커버리지보다는 핵심 비즈니스 로직과 복잡한 조건문, 에러 처리 로직이 충분히 테스트되었는지에 집중합니다. 테스트 품질은 뮤테이션 테스트로 평가해 테스트가 실제로 버그를 잡아낼 수 있는지 확인하고, 테스트 코드의 가독성과 유지보수성도 중요한 지표입니다. 프로덕션 버그 중 테스트로 예방 가능했던 비율을 추적하며, 테스트 실행 시간과 안정성도 모니터링합니다. 팀 내에서는 커버리지 하한선을 설정하되 강제하기보다는 가이드라인으로 활용하며, 코드 리뷰에서 중요한 로직의 테스트 누락을 확인합니다.

Mock은 호출 여부와 인자를 검증하는 객체로, API 호출 함수가 올바른 파라미터로 호출되었는지 확인할 때 사용합니다. Stub은 미리 정해진 값을 반환하는 객체로, 외부 의존성의 응답을 제어해 다양한 시나리오를 테스트할 때 활용합니다. Spy는 실제 함수를 래핑해 호출을 기록하면서 원래 동작도 수행하므로, 함수 호출 여부를 확인하면서 실제 로직도 실행해야 할 때 사용합니다. Svelte에서 store를 테스트할 때는 Stub으로 초기값을 설정하고, 컴포넌트가 store를 구독하는지 Spy로 확인하며, API 호출은 Mock으로 호출 검증과 응답 제어를 동시에 합니다. 과도한 Mock 사용은 구현 세부사항에 의존하게 만들므로, 가능하면 실제 객체를 사용하고 외부 의존성만 대체합니다.

렌더링 성능은 Vitest의 benchmark API나 별도의 벤치마크 도구를 사용해 컴포넌트 마운트 시간과 업데이트 시간을 측정합니다. performance.now()로 반응성 업데이트 전후 시간을 측정하고, 대량의 데이터 렌더링이나 복잡한 계산이 포함된 시나리오를 테스트합니다. 기준 성능을 설정하고 임계값을 초과하면 테스트가 실패하도록 구성해 성능 회귀를 조기에 발견합니다. CI 파이프라인에서 성능 테스트를 실행하고 결과를 시계열로 추적해 트렌드를 모니터링합니다. Lighthouse CI를 통합해 전체 애플리케이션의 Core Web Vitals도 자동으로 측정하며, 각 배포마다 성능 보고서를 생성합니다. 성능 병목이 발견되면 프로파일러로 원인을 분석하고, 최적화 후 벤치마크로 개선 효과를 정량적으로 검증합니다.

테스트는 AAA 패턴(Arrange-Act-Assert)으로 구조화해 가독성을 높이고, 테스트 헬퍼 함수와 커스텀 렌더러로 중복을 제거합니다. Page Object 패턴이나 Testing Library의 커스텀 쿼리를 만들어 UI 변경에 대한 영향을 최소화하고, 구현 세부사항이 아닌 사용자 관점의 동작을 테스트합니다. 테스트 데이터는 Factory 패턴이나 Fixture로 관리해 일관성을 유지하며, 각 테스트는 독립적으로 실행 가능하도록 격리합니다. 하나의 테스트에서 하나의 개념만 검증하고, 테스트 이름은 무엇을 테스트하는지 명확하게 작성합니다. 깨지기 쉬운 테스트를 방지하려면 내부 구현이 아닌 공개 API를 테스트하고, 불필요한 Mock 사용을 줄이며, 타이밍에 의존하는 테스트는 명시적인 대기를 사용합니다.

모노레포에서는 변경된 패키지만 테스트하도록 affected 분석을 적용해 불필요한 테스트 실행을 줄입니다. 단위 테스트는 모든 커밋에서 실행하고, 통합 테스트는 PR 단계에서, E2E 테스트는 머지 전과 배포 전에 실행하는 계층별 전략을 사용합니다. 테스트를 병렬로 실행해 전체 실행 시간을 단축하고, 실패한 테스트를 먼저 실행하는 fail-fast 전략으로 빠른 피드백을 제공합니다. 테스트 결과를 캐싱해 변경되지 않은 부분은 이전 결과를 재사용하며, Docker 레이어 캐싱으로 의존성 설치 시간을 최적화합니다. 각 단계별 테스트 결과를 대시보드로 시각화하고, 불안정한 테스트는 자동으로 표시해 관리합니다. 프로덕션과 유사한 스테이징 환경에서 smoke 테스트를 실행해 배포 전 최종 검증을 수행합니다.