React Native 신입 테스트 및 코드품질 기술면접
새 면접Q. React Native 프로젝트에서 사용할 수 있는 주요 테스트 프레임워크와 라이브러리를 설명하고, 각각의 역할을 말씀해주세요.
Jest와 React Native Testing Library의 차이와 각각이 담당하는 부분을 생각해보세요.
React Native에서는 주로 Jest를 테스트 러너로 사용합니다. Jest는 테스트를 실행하고 모킹, 스냅샷 테스트 등을 제공하는 프레임워크입니다. React Native Testing Library는 컴포넌트를 렌더링하고 사용자 관점에서 테스트할 수 있게 도와주는 유틸리티 라이브러리입니다. Detox는 E2E 테스트를 위한 프레임워크로 실제 앱 동작을 시뮬레이션합니다. 일반적으로 Jest와 Testing Library를 함께 사용하여 단위 및 통합 테스트를 작성합니다.
- • Jest는 테스트 러너이자 프레임워크
- • React Native Testing Library는 컴포넌트 테스트 유틸리티
- • Detox는 E2E 테스트 도구
프로젝트 초기 테스트 환경을 구축할 때 각 도구의 역할을 이해하고 적절히 조합해야 합니다.
Jest의 스냅샷 테스트는 어떤 경우에 유용하고, 어떤 단점이 있을까요?
Q. React Native 컴포넌트를 테스트할 때 render 함수와 screen 객체를 어떻게 사용하는지 설명해주세요.
Testing Library의 render로 컴포넌트를 그리고, screen으로 요소를 찾는 과정을 생각해보세요.
render 함수는 Testing Library에서 제공하며 테스트하려는 컴포넌트를 가상 환경에 렌더링합니다. 렌더링 후 screen 객체를 통해 화면에 표시된 요소를 찾을 수 있습니다. screen.getByText, screen.getByTestId 같은 쿼리 메서드로 특정 요소를 선택합니다. 예를 들어 버튼 컴포넌트를 테스트할 때 render로 컴포넌트를 그리고 screen.getByText로 버튼 텍스트를 찾아 검증합니다. 이 방식은 사용자가 화면을 보는 것처럼 테스트할 수 있게 해줍니다.
- • render는 컴포넌트를 테스트 환경에 렌더링
- • screen은 렌더링된 요소를 찾는 객체
- • 사용자 관점의 테스트 가능
로그인 버튼이나 제목 텍스트가 제대로 표시되는지 확인하는 기본적인 UI 테스트에서 사용합니다.
getByText와 queryByText의 차이점은 무엇이며, 각각 어떤 상황에 사용하나요?
Q. 좋은 테스트 코드의 특징을 3가지 이상 설명하고, 각각이 왜 중요한지 말씀해주세요.
테스트의 독립성, 가독성, 유지보수성 측면에서 생각해보세요.
첫째, 테스트는 독립적이어야 합니다. 각 테스트가 서로 영향을 주지 않아야 실행 순서에 관계없이 안정적인 결과를 얻습니다. 둘째, 테스트는 읽기 쉬워야 합니다. 테스트 이름과 코드만으로 무엇을 검증하는지 명확히 알 수 있어야 유지보수가 용이합니다. 셋째, 테스트는 빠르게 실행되어야 합니다. 느린 테스트는 개발자가 자주 실행하지 않게 되어 버그 발견이 늦어집니다. 넷째, 하나의 테스트는 하나의 관심사만 검증해야 합니다. 이렇게 하면 실패 시 원인을 빠르게 파악할 수 있습니다.
- • 테스트의 독립성으로 안정적인 실행
- • 가독성으로 유지보수 용이
- • 빠른 실행으로 개발 속도 향상
- • 단일 관심사로 명확한 실패 원인 파악
팀 프로젝트에서 다른 개발자가 작성한 테스트를 이해하고 수정할 때 이러한 원칙이 중요합니다.
테스트 간 독립성을 보장하기 위해 beforeEach나 afterEach를 어떻게 활용할 수 있나요?
Q. React Native 컴포넌트에서 중복 코드가 많아졌을 때 리팩토링하는 방법을 설명해주세요. 어떤 기준으로 코드를 분리하나요?
재사용 가능한 컴포넌트 추출과 커스텀 훅 분리를 생각해보세요.
중복되는 UI 요소는 재사용 가능한 컴포넌트로 분리합니다. 예를 들어 여러 곳에서 사용하는 버튼이나 카드 레이아웃을 별도 컴포넌트로 만듭니다. 중복되는 로직은 커스텀 훅으로 추출합니다. API 호출이나 폼 관리 로직 같은 것들이 해당됩니다. 컴포넌트가 너무 커지면 단일 책임 원칙에 따라 기능별로 분리합니다. 리팩토링 후에는 반드시 기존 테스트가 통과하는지 확인하여 동작이 변경되지 않았음을 검증합니다. 이러한 리팩토링은 코드의 가독성과 유지보수성을 높입니다.
- • 중복 UI는 컴포넌트로 분리
- • 중복 로직은 커스텀 훅으로 추출
- • 단일 책임 원칙 적용
- • 리팩토링 후 테스트로 검증
여러 화면에서 비슷한 리스트나 폼을 사용할 때 공통 컴포넌트로 추출하여 코드 중복을 줄입니다.
리팩토링을 할 때 기존 기능이 깨지지 않았음을 어떻게 보장할 수 있나요?
Q. TDD(Test-Driven Development)의 개발 사이클을 설명하고, 이 방식의 장점을 말씀해주세요.
Red-Green-Refactor 사이클과 테스트를 먼저 작성하는 이유를 생각해보세요.
TDD는 Red-Green-Refactor 사이클로 진행됩니다. 먼저 실패하는 테스트를 작성하고(Red), 테스트를 통과하는 최소한의 코드를 구현한 후(Green), 코드를 개선합니다(Refactor). 이 방식의 장점은 요구사항을 명확히 이해하고 시작하게 된다는 점입니다. 또한 테스트 가능한 코드 구조를 자연스럽게 만들게 되며, 리팩토링 시 안전망 역할을 합니다. 코드 작성 전 테스트를 먼저 쓰면 불필요한 코드를 줄이고 필요한 기능에만 집중할 수 있습니다.
- • Red-Green-Refactor 사이클
- • 요구사항의 명확한 이해
- • 테스트 가능한 구조
- • 리팩토링 안전망
새로운 기능을 추가할 때 예상 동작을 테스트로 먼저 정의하면 구현 방향이 명확해집니다.
TDD를 실제 프로젝트에 적용할 때 어려운 점은 무엇이며, 어떻게 극복할 수 있을까요?
Q. 코드 리뷰를 할 때 주로 어떤 점들을 확인해야 하는지 설명해주세요.
코드의 정확성, 가독성, 테스트, 성능 등 다양한 측면을 고려해보세요.
코드 리뷰에서는 먼저 코드가 요구사항을 올바르게 구현했는지 확인합니다. 변수명과 함수명이 명확하고 일관된 네이밍 규칙을 따르는지 검토합니다. 중복 코드나 불필요한 복잡성이 없는지 살펴봅니다. 새로운 기능에 대한 테스트가 작성되었는지, 기존 테스트가 통과하는지 확인합니다. 잠재적인 버그나 엣지 케이스 처리가 누락되지 않았는지 체크합니다. 또한 코드 스타일 가이드를 준수하는지, 주석이 필요한 복잡한 로직에는 설명이 있는지 확인합니다.
- • 요구사항 충족 여부
- • 네이밍과 가독성
- • 테스트 존재 여부
- • 잠재적 버그 확인
- • 코드 스타일 준수
Pull Request를 검토할 때 이러한 체크리스트로 코드 품질을 유지하고 팀의 코딩 표준을 지킵니다.
코드 리뷰에서 피드백을 줄 때 어떤 태도와 방식이 좋을까요?
Q. 테스트 커버리지가 무엇인지 설명하고, 커버리지가 높다고 해서 무조건 좋은 것은 아닌 이유를 말씀해주세요.
커버리지의 정의와 함께 테스트의 질적인 측면을 고려해보세요.
테스트 커버리지는 전체 코드 중 테스트로 실행된 코드의 비율을 나타내는 지표입니다. 주로 라인 커버리지, 분기 커버리지 등으로 측정합니다. 하지만 커버리지가 높다고 해서 테스트 품질이 좋다고 할 수 없습니다. 단순히 코드를 실행만 하고 제대로 된 검증(assertion)이 없으면 의미가 없기 때문입니다. 또한 중요한 엣지 케이스나 에러 상황을 놓칠 수 있습니다. 따라서 커버리지는 참고 지표로 활용하되, 의미 있는 시나리오를 테스트하는 것이 더 중요합니다.
- • 커버리지는 코드 실행 비율 지표
- • 높은 커버리지가 품질을 보장하지 않음
- • 검증(assertion)의 중요성
- • 의미 있는 시나리오 테스트가 핵심
CI/CD 파이프라인에서 커버리지를 측정하여 테스트되지 않은 코드 영역을 파악하고 개선합니다.
프로젝트에서 적절한 테스트 커버리지 목표는 몇 퍼센트 정도로 설정하는 것이 좋을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!