Nuxt.js 주니어 테스트 · 코드품질 기술면접
새 면접Q. Nuxt.js 프로젝트에서 Vue 컴포넌트의 단위 테스트를 작성할 때 주로 사용하는 테스트 라이브러리는 무엇이며, 기본적으로 어떤 것들을 테스트해야 하나요?
Vue Test Utils와 테스트 러너를 함께 고려해보세요.
Nuxt.js에서는 주로 Vitest 또는 Jest를 테스트 러너로 사용하고, @vue/test-utils를 활용해 컴포넌트를 마운트하고 테스트합니다. 기본적으로 컴포넌트가 올바르게 렌더링되는지, props가 제대로 전달되는지, 사용자 이벤트(클릭, 입력 등)에 대한 반응이 정확한지를 테스트해야 합니다. 또한 computed 속성이나 method의 동작, emit된 이벤트가 올바른 값과 함께 발생하는지 검증합니다. 조건부 렌더링이나 v-if, v-show 같은 디렉티브의 동작도 테스트 대상에 포함됩니다.
- • Vitest 또는 Jest와 @vue/test-utils 조합 사용
- • 렌더링, props, 이벤트 핸들링 테스트
- • computed, methods, emit 이벤트 검증
- • 조건부 렌더링 동작 확인
신규 기능 개발 시 컴포넌트의 예상 동작을 보장하고 리팩토링 후에도 기능이 정상 작동하는지 자동으로 검증할 수 있습니다.
shallowMount와 mount의 차이점은 무엇이며, 각각 언제 사용하는 것이 좋을까요?
Q. Nuxt.js에서 useFetch나 $fetch를 사용하는 컴포넌트를 테스트할 때, 실제 API 호출 없이 테스트하려면 어떻게 해야 하나요?
테스트 환경에서 HTTP 요청을 가로채는 방법을 생각해보세요.
API 호출을 모킹하기 위해 MSW(Mock Service Worker)를 사용하거나, vi.mock 또는 jest.mock을 활용해 useFetch 자체를 모킹할 수 있습니다. MSW를 사용하면 실제 HTTP 요청을 가로채서 미리 정의한 응답을 반환하므로 더 현실적인 테스트가 가능합니다. vi.mock을 사용할 경우 '#app' 모듈의 useFetch를 직접 모킹하여 원하는 데이터나 에러 상태를 반환하도록 설정합니다. 모킹을 통해 네트워크 의존성을 제거하고 테스트 속도를 높이며, 다양한 응답 시나리오(성공, 실패, 로딩)를 쉽게 재현할 수 있습니다.
- • MSW 또는 vi.mock/jest.mock 활용
- • useFetch나 $fetch 모킹으로 네트워크 의존성 제거
- • 성공, 실패, 로딩 등 다양한 시나리오 테스트
- • 테스트 속도 향상 및 안정성 확보
외부 API 서버 상태에 관계없이 안정적으로 테스트를 실행하고, 에러 상황이나 엣지 케이스를 쉽게 재현할 수 있습니다.
API 응답이 지연되는 상황을 테스트하려면 어떻게 해야 할까요?
Q. Nuxt.js에서 작성한 커스텀 composable 함수를 테스트할 때 주의해야 할 점과 테스트 방법을 설명해주세요.
Vue의 reactivity 시스템과 컴포지션 API의 실행 컨텍스트를 고려해보세요.
Composable은 Vue의 컴포지션 API 컨텍스트 내에서 실행되어야 하므로, 단순히 함수를 호출하는 것만으로는 테스트할 수 없습니다. @vue/test-utils의 mount를 사용해 더미 컴포넌트를 만들고 그 안에서 composable을 호출하거나, @nuxt/test-utils의 mountSuspended를 활용할 수 있습니다. Composable이 반환하는 ref나 computed 값의 변화를 추적하고, 함수 호출 시 상태가 올바르게 업데이트되는지 검증합니다. 또한 composable이 다른 Nuxt 기능(useRuntimeConfig, useFetch 등)에 의존한다면 이들도 적절히 모킹해야 합니다.
- • Vue 컴포지션 API 컨텍스트 내에서 실행 필요
- • 더미 컴포넌트 또는 mountSuspended 활용
- • ref, computed 값의 변화 추적 및 검증
- • 의존하는 Nuxt 기능 모킹
비즈니스 로직을 composable로 분리했을 때, 로직의 정확성을 독립적으로 검증하여 유지보수성을 높일 수 있습니다.
여러 composable이 서로 의존하는 경우 테스트 전략은 어떻게 달라지나요?
Q. Nuxt.js 프로젝트에서 여러 페이지에 중복된 코드가 많아 유지보수가 어려워졌습니다. 코드 중복을 제거하고 재사용성을 높이기 위한 리팩토링 방법을 설명해주세요.
Nuxt의 구조적 특징인 composables, components, layouts, utils를 활용해보세요.
먼저 중복된 비즈니스 로직이나 상태 관리 코드는 composables 디렉토리에 커스텀 composable로 추출합니다. UI 요소의 중복은 components 디렉토리에 재사용 가능한 컴포넌트로 분리하고, 필요하다면 props와 slots을 활용해 유연성을 높입니다. 페이지 레이아웃의 공통 부분은 layouts 디렉토리에 정의하여 여러 페이지에서 공유합니다. 순수 함수나 유틸리티 로직은 utils 디렉토리에 분리하여 어디서든 import해서 사용할 수 있게 합니다. 리팩토링 후에는 기존 테스트가 통과하는지 확인하고, 새로 분리한 모듈에 대한 단위 테스트를 추가합니다.
- • 비즈니스 로직을 composables로 추출
- • UI 중복을 재사용 가능한 컴포넌트로 분리
- • 공통 레이아웃을 layouts에 정의
- • 순수 함수는 utils로 분리하고 테스트 추가
프로젝트가 성장하면서 발생하는 코드 중복을 체계적으로 제거하여 버그 수정과 기능 추가가 용이해집니다.
리팩토링 전후로 코드 품질이 개선되었는지 어떻게 측정할 수 있을까요?
Q. Nuxt.js에서 페이지 전체의 동작을 검증하는 통합 테스트를 작성할 때, 단위 테스트와 어떤 점이 다르며 어떤 것들을 테스트해야 하나요?
여러 컴포넌트와 모듈이 함께 동작하는 시나리오를 생각해보세요.
통합 테스트는 단위 테스트와 달리 여러 컴포넌트, composable, API 호출이 함께 동작하는 전체 플로우를 검증합니다. @nuxt/test-utils의 mountSuspended나 Playwright, Cypress 같은 E2E 도구를 활용할 수 있습니다. 사용자 여정(로그인 -> 데이터 조회 -> 수정 -> 저장)처럼 실제 사용 시나리오를 테스트하고, 라우팅, 상태 관리, API 통신이 올바르게 연동되는지 확인합니다. 페이지 간 네비게이션, 전역 상태 변화, 에러 핸들링 등 시스템의 여러 부분이 통합되어 작동하는 것을 검증하는 것이 목표입니다.
- • 여러 모듈이 함께 동작하는 전체 플로우 검증
- • 실제 사용자 여정 시나리오 테스트
- • 라우팅, 상태 관리, API 통신 연동 확인
- • mountSuspended 또는 E2E 도구 활용
주요 비즈니스 플로우가 배포 전에 정상 작동하는지 자동으로 검증하여 프로덕션 버그를 사전에 방지합니다.
통합 테스트가 실패했을 때 원인을 빠르게 찾기 위한 디버깅 전략은 무엇인가요?
Q. Nuxt.js 프로젝트에서 동료가 작성한 PR을 코드 리뷰할 때, 특히 주의 깊게 확인해야 할 코드 품질 요소는 무엇인가요?
Nuxt의 특성과 Vue 컴포넌트 구조, 그리고 일반적인 코드 품질 기준을 함께 고려해보세요.
먼저 컴포넌트가 단일 책임 원칙을 따르고 있는지, 너무 많은 역할을 하지 않는지 확인합니다. Props와 emits가 명확히 정의되어 있고 타입이 지정되어 있는지, 불필요한 전역 상태 사용은 없는지 점검합니다. useFetch나 useAsyncData 같은 Nuxt 기능을 올바르게 사용하고 있는지, 특히 SSR 환경에서 문제가 없는지 확인합니다. 코드 중복이 있다면 재사용 가능한 composable이나 컴포넌트로 분리할 것을 제안하고, 테스트 코드가 함께 작성되었는지도 확인합니다. 네이밍이 명확하고 일관성 있는지, 주석이 필요한 복잡한 로직에는 설명이 있는지도 살펴봅니다.
- • 단일 책임 원칙과 컴포넌트 크기 확인
- • Props, emits 타입 정의 및 전역 상태 사용 점검
- • Nuxt 기능의 올바른 사용과 SSR 호환성
- • 코드 중복 제거 및 테스트 코드 존재 여부
- • 네이밍 일관성과 주석 적절성
체계적인 코드 리뷰를 통해 팀 전체의 코드 품질을 일정 수준 이상으로 유지하고 지식을 공유할 수 있습니다.
코드 리뷰에서 의견 충돌이 발생했을 때 어떻게 해결하시나요?
Q. Nuxt.js 프로젝트에서 테스트 커버리지를 측정하고 관리하는 것이 왜 중요하며, 어떤 도구로 측정할 수 있나요?
코드의 어느 부분이 테스트되지 않았는지 파악하는 방법을 생각해보세요.
테스트 커버리지는 전체 코드 중 테스트로 실행된 부분의 비율을 나타내며, 테스트되지 않은 코드를 파악해 테스트 누락을 방지하는 데 중요합니다. Vitest나 Jest는 기본적으로 커버리지 측정 기능을 제공하며, vitest --coverage 또는 jest --coverage 명령으로 실행할 수 있습니다. 커버리지 리포트는 라인, 브랜치, 함수, 구문 커버리지를 보여주며, HTML 리포트로 시각화하여 어느 파일의 어느 라인이 테스트되지 않았는지 확인할 수 있습니다. 다만 높은 커버리지가 곧 좋은 테스트를 의미하지는 않으므로, 중요한 비즈니스 로직과 엣지 케이스를 우선적으로 테스트하는 것이 중요합니다.
- • 테스트되지 않은 코드 파악으로 테스트 누락 방지
- • Vitest 또는 Jest의 커버리지 측정 기능 활용
- • 라인, 브랜치, 함수, 구문 커버리지 확인
- • 높은 커버리지보다 중요한 로직의 품질 있는 테스트가 우선
CI/CD 파이프라인에서 커버리지 임계값을 설정하여 테스트 품질이 떨어지는 코드가 배포되는 것을 방지할 수 있습니다.
테스트 커버리지 목표를 몇 퍼센트로 설정하는 것이 적절하다고 생각하시나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!