10. 🛡️ 견고한 코드를 위한 테스트 전략과 자동화

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 22분 (핵심 요약: 11분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: 테스트 피라미드 & 전략] → [질문 2: 컴포넌트 테스트 (RTL)] → [실전 변형 질문]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• 단위 테스트와 통합 테스트의 차이와 각각의 적절한 비율을 결정합니다.
• '사용자 중심'의 테스트를 위해 React Testing Library를 활용하는 법을 익힙니다.
• 회귀 테스트(Regression Test)가 유지보수 비용을 어떻게 줄여주는지 이해합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. 테스트 피라미드 (Testing Pyramid)

하단(Unit)은 많고 상단(E2E)은 적은 구조의 테스트 전략입니다. 비용이 싸고 빠른 단위 테스트를 기반으로 하고, 복잡하고 느린 통합/E2E 테스트는 핵심 흐름에만 집중합니다.

2. RTL (React Testing Library)

컴포넌트의 내부 구현(state, props)이 아니라, 사용자가 화면에서 보는 결과물(text, role 등)을 중심으로 테스트하는 라이브러리입니다. 코드 리팩토링 시 테스트가 깨지지 않는 안전함을 줍니다.

3. 모킹 (Mocking)

실제 데이터베이스나 외부 API 대신 가짜 데이터를 사용하여 테스트 환경을 격리하는 기술입니다. 외부 환경에 의존하지 않고 항상 일관된 테스트 결과를 얻기 위해 필수적입니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "영호 님! '영수네 댓글' 기능을 하나 고쳤는데 멀쩡하던 '게시글 수정'이 터졌어요! 😱 사람이 일일이 다 눌러볼 수도 없고... 테스트 코드 짜면 진짜 이런 거 다 잡아주나요?"
• 🦁 영호 ( 리드 ): "영철 님, 테스트는 '나중에 귀찮지 않으려고 지금 귀찮음을 감수하는 일'입니다. 테스트 코드가 있다면 우리는 어제의 내가 짠 코드를 믿고 오늘 마음껏 리팩토링할 수 있죠. 자, 어떤 걸 먼저 테스트할지 피라미드부터 세워봅시다."

Q1. 단위 테스트(Unit Test)와 통합 테스트(Integration Test)의 차이점은 무엇이며, 실무에서 어떤 비중으로 작성하시나요?

🎯 출제 의도

테스트의 비용과 가치를 이해하고 있는지 확인합니다. 모든 코드에 테스트를 짜는 것은 불가능하므로, 효율적인 테스트 전략을 세울 수 있는 판단력을 평가합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 모든 작은 함수 하나하나에 테스트를 짜느라 비즈니스 로직 개발 속도가 너무 느려졌습니다.

// 🐣 영철: "1 + 1 함수도 테스트를 짜야 안심이 돼요!"
test('add function', () => {
    expect(add(1, 1)).toBe(2); // ⚠️ 너무 사소한 테스트에 에너지를 낭비 중
});
// ⚠️ 문제: 실제 컴포넌트가 서버와 어떻게 통신하는지 등 정작 중요한 '흐름'은 테스트 안 함

🦁 영호의 팩폭 조언
"영철 님, 함수가 잘 도는 것도 중요하지만 더 중요한 건 사용자가 원하는 결과가 나오느냐입니다. 사소한 유틸리티 함수 100개보다, '로그인 후 게시글 쓰기'라는 하나의 흐름을 테스트하는 게 훨씬 가치 있어요."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 제안하는 균형 잡힌 테스트 비중입니다.

// 🦁 영호: "비즈니스 핵심 로직은 단위 테스트로, 컴포넌트 간 협업은 통합 테스트로 잡으세요."
 
// 1. 단위 테스트 (Unit): 
// - 복잡한 계산식, 순수 함수, 비즈니스 규칙 (예: 포인트 적립 계산 로직)
// - 비중: 60% (빠르고 정확함)
 
// 2. 통합 테스트 (Integration):
// - 훅과 컴포넌트의 상호작용, API 모킹 데이터와 UI의 연동
// - 비중: 30% (실제 사용자와 가장 가까운 가치 제공)
 
// 3. E2E 테스트 (Playwright/Cypress):
// - 결제 성공, 회원가입 등 핵심 비즈니스 크리티컬 패스
// - 비중: 10% (느리지만 확실한 보증)

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "단위 테스트는 작은 함수를, 통합 테스트는 여러 개가 합쳐진 것을 테스트합니다. 둘 다 많이 짜면 좋습니다."
• Level 2 (Senior): "단위 테스트는 격리된 환경에서 세부 로직을 검증하고, 통합 테스트는 리액트 컴포넌트 트리가 실제 비즈니스 요구사항대로 렌더링되는지 확인함을 설명합니다. ROI(투자 대비 효과) 관점에서 통합 테스트의 비중을 높여 '리팩토링 내성'을 확보하는 전략을 제시합니다."
• Level 3 (Specialist): "TDD(Test Driven Development)를 통한 설계 개선 사례를 설명합니다. 또한 MSW(Mock Service Worker)를 활용해 네트워크 계층까지 모킹하여 프론트엔드 테스트 환경을 실제와 가깝게 구축한 경험을 분석합니다. '테스트를 위해 테스트를 짜는 것'이 아닌, 코드의 설계 수준을 높이는 도구로서의 테스트를 강조합니다."

Q2. React Testing Library(RTL)에서 '구현 세부 정보'가 아닌 '사용자 관점'으로 테스트를 작성해야 하는 이유는 무엇인가요?

🎯 출제 의도

코드를 고쳤을 때 테스트가 깨지는 '취약한 테스트'의 문제를 인지하고 있는지 확인합니다. 변화에 유연한 견고한 테스트 코드를 짤 수 있는지 평가합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 컴포넌트 내부의 state 값이나 함수 이름이 정확한지 테스트하려 합니다.

// 🐣 영철: "내부의 isOpen 상태가 true인지 확인하면 되겠죠?"
const wrapper = shallow(<Modal />);
expect(wrapper.state('isOpen')).toBe(true); 
// ⚠️ 문제: state 이름을 'isVisible'로 바꾸는 순간, 기능은 멀쩡해도 테스트는 깨짐 (리팩토링 방해)

🦁 영호의 팩폭 조언
"영철 님, 사용자는 컴포넌트 이름이 뭔지, 상태 변수명이 뭔지 관심 없어요. 오직 '화면에 모달이 떴는가'만 관심 있죠. 사용자의 눈으로 코드를 보세요."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 RTL의 철학을 담은 테스트를 보여줍니다.

// 🦁 영호: "사용자가 보는 텍스트, 버튼 속성으로 접근하세요."
 
import { render, screen, fireEvent } from '@testing-library/react';
 
test('모달 열기 버튼을 누르면 환영 메시지가 나타난다', () => {
    render(<WelcomeModal />);
    
    // 1. "모달 열기"라고 써진 버튼을 찾아서 클릭 (사용자 행위)
    const openBtn = screen.getByRole('button', { name: /모달 열기/i });
    fireEvent.click(openBtn);
    
    // 2. 화면에 "환영합니다"라는 글자가 있는지 확인 (사용자 경험)
    expect(screen.getByText(/환영합니다/i)).toBeInTheDocument();
    
    // ✅ 이제 내부 변수명을 아무리 바꿔도 기능만 같으면 이 테스트는 통과합니다!
});

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "RTL은 사용자가 보는 것을 테스트하는 라이브러리입니다. 그래야 기능이 바뀌어도 테스트가 잘 돌아갑니다."
• Level 2 (Senior): "브라우저 접근성(Accessibility)을 고려한 getByRole, getByLabelText 등의 쿼리를 우선 사용하는 이유를 설명합니다. 이는 테스트의 견고함을 높일 뿐만 아니라 웹 접근성을 강제하는 부수 효과가 있음을 언급합니다."
• Level 3 (Specialist): "'화이트박스 테스트'와 '블랙박스 테스트'의 개념을 연결합니다. 내부 구현을 모르는 상태에서 입출력(UI 상호작용과 결과)만 검증하는 블랙박스 테스트가 리팩토링 효율을 얼마나 극대화하는지 사례를 제시합니다. 또한 비동기 테스트 시 findBy 쿼리와 waitFor를 정확히 사용하는 메커니즘을 분석합니다."

🔗 실전 변형 질문 (Related Variations)

Q175. TDD(테스트 주도 개발)의 사이클과 실무에서의 현실적인 적용 방안은?

• 🎯 출제 의도: 이론적인 TDD 지식을 넘어, 실제 업무 속도와 품질 사이의 균형을 맞출 줄 아는지 확인합니다.
• 💡 핵심 원리 & 답변: TDD는 Red(실패하는 테스트) → Green(구현) → Refactor(개선) 순서로 진행됩니다. 하지만 모든 기능에 적용하긴 힘들 수 있습니다. 실무에서는 복잡한 엣지 케이스가 많은 공통 유틸리티 함수나, 서버 응답에 따라 UI가 민감하게 변하는 복잡한 비즈니스 폼 로직 등에 선택적으로 적용하여 설계의 완성도를 높이는 것이 현실적입니다.

Q180. 스냅샷 테스트(Snapshot Testing)의 장단점과 언제 사용하면 유효한가요?

• 🎯 출제 의도: 테스트의 편리함 뒤에 숨은 위험성(무의미한 업데이트)을 인지하고 있는지 확인합니다.
• 💡 핵심 원리 & 답변: 스냅샷 테스트는 이전 UI 결과물과 현재를 비교하여 의도치 않은 변화를 감지하는 데 매우 빠르고 편리합니다. 하지만 조금만 스타일을 고쳐도 테스트가 깨져 수동으로 업데이트해야 하는 번거로움이 커질 수 있습니다. 따라서 로직이 자주 바뀌는 컴포넌트보다는, 디자인 시스템의 공통 UI 컴포넌트나 절대 바뀌면 안 되는 설치형 라이브러리 등의 회귀 방지 목적으로 사용하는 것이 가장 좋습니다.

Q195. 좋은 테스트 코드의 5대 원칙(FIRST)이란 무엇인가요?

• 🎯 출제 의도: 테스트 코드 자체가 유지보수하기 좋은 '품질'을 갖추고 있는지 확인합니다.
• 💡 핵심 원리 & 답변: FIRST 원칙은 Fast(빠르게 실행), Independent(독립적 실행), Repeatable(어디서든 같은 결과), Self-Validating(성공/실패 여부 자동 판별), Timely(코드 구현 전후 적시에 작성)를 의미합니다. 특히 독립성과 반복 가능성이 중요한데, 이전 테스트의 상태가 다음 테스트에 영향을 주지 않도록 매번 환경을 초기화하는 것이 좋은 테스트의 기초입니다.

🐣 영철이의 복기 일기

오늘 테스트 코드를 짜보면서 느꼈다. 그동안 나는 "제발 버그 안 나게 해주세요"라고 기도하며 코딩했는데, 이제는 "이 테스트가 내 코드를 지켜주고 있다"는 든든한 방패를 얻었다. 특히 '사용자 관점'에서 테스트를 짜는 법을 배우니, 내가 만드는 기능이 진짜 사용자에게 어떤 가치를 주는지 다시 한번 생각하게 되었다.

💡 "테스트 코드는 미래의 내가 과거의 나에게 감사를 표하게 만드는 최고의 선물이다."

내일은 웹을 위협하는 어둠의 그림자(?)를 막는 법, '보안 & 성능 엔지니어링 2탄'을 배운다. 보안은 뚫려야 아는 법이라는데 미리미리 잘 막아야지! 🔐⚔️