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 대신 가짜 데이터를 사용하여 테스트 환경을 격리하는 기술입니다. 외부 환경에 의존하지 않고 항상 일관된 테스트 결과를 얻기 위해 필수적입니다.

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

• 🐣 영철 (후반): "영호 님! '영수네 댓글' 기능을 하나 고쳤는데 멀쩡하던 '게시글 수정' 흐름에서 회귀가 생겼습니다. 사람이 일일이 다 눌러볼 수도 없고, 어떤 테스트부터 추가해야 할까요?"
• 🦁 영호 (리드): "영철 님, 테스트는 나중에 덜 불안하게 바꾸기 위해 지금 사용자 약속을 기록하는 일입니다. 테스트 코드가 있다면 우리는 어제의 기능을 믿고 오늘 리팩토링할 수 있죠. 어떤 위험을 먼저 막을지 피라미드부터 세워봅시다."

면접 질문 1. 단위 테스트(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% (느리지만 확실한 보증)

비율은 팀과 서비스에 따라 달라질 수 있습니다. 중요한 것은 "빠른 단위 테스트로 계산 규칙을 지키고, 통합 테스트로 사용자 흐름을 지키며, E2E는 장애 비용이 큰 핵심 경로에 집중한다"는 판단 기준입니다.

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

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

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

userEvent는 클릭, 입력, 포커스 이동처럼 실제 사용자 이벤트에 가까운 순서로 동작합니다. 그래서 RTL 답변에서는 내부 state를 직접 확인하는 대신 접근 가능한 role과 사용자 행동을 기준으로 검증한다고 설명하는 것이 좋습니다.

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

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

🔗 실전 변형 질문 (Related Variations)

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

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

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

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

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

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

📝 마무리 퀴즈

Q1. 테스트 피라미드를 설명할 때 "단위 테스트를 많이, E2E를 적게"라고만 말하면 부족한 이유는 무엇인가요?

✅ 정답: 각 테스트가 보장하는 범위와 비용이 다르므로, 비즈니스 위험과 변경 빈도에 맞춰 조합해야 하기 때문

💡 상세 해설:

• 원리 설명: 단위 테스트는 빠르고 정확하지만 통합 흐름을 보장하지 못합니다. E2E는 사용자 흐름을 검증하지만 느리고 유지비가 큽니다. 면접에서는 어떤 위험을 어떤 테스트로 막을지 말해야 합니다.
• 오답 피드백: 비율만 외우면 실제 프로젝트의 결제, 인증, 권한 같은 핵심 경로를 어떻게 보호할지 설명할 수 없습니다.
• 📌 핵심 기억법: 테스트 전략은 숫자 비율보다 위험 배분입니다.

Q2. React Testing Library가 구현 세부보다 사용자 관점의 쿼리를 권장하는 이유는 무엇인가요?

✅ 정답: 내부 state나 함수 이름이 바뀌어도 사용자가 보는 결과와 접근 가능한 역할이 유지되면 테스트가 깨지지 않기 때문

💡 상세 해설:

• 원리 설명: getByRole, getByLabelText 같은 쿼리는 사용자가 실제로 상호작용하는 표면을 기준으로 테스트합니다. 동시에 접근성 품질도 강제합니다.
• 오답 피드백: 컴포넌트 내부 변수나 className에 의존하면 리팩토링만 해도 테스트가 깨지는 취약한 테스트가 됩니다.
• 📌 핵심 기억법: 좋은 테스트는 구현이 아니라 사용자 약속을 붙잡습니다.

Q3. 영철이의 테스트 타임: 영수네 댓글 수정 버그를 다시 막으려면 어떤 테스트부터 추가해야 하나요?

✅ 정답: 댓글 수정 후 목록과 상세 화면이 기대한 텍스트를 보여주는 사용자 흐름 중심의 통합 테스트

💡 상세 해설:

• 원리 설명: 이미 발생한 회귀는 비즈니스 흐름으로 재현하는 테스트가 가장 강한 보호막이 됩니다. 필요한 API는 mock하되, 사용자 행동과 결과는 실제에 가깝게 검증합니다.
• 오답 피드백: 단순 유틸 함수 테스트만 추가하면 같은 UI 회귀를 막지 못할 수 있습니다.
• 📌 핵심 기억법: 버그가 난 길을 테스트가 다시 걸어가게 만듭니다.

🐣 영철이의 퇴근 일기

오늘은 테스트를 "일단 많이 짜면 좋은 것"으로 보던 생각을 고쳤다. 영수네 댓글 버그를 다시 막으려면 함수 하나가 아니라 사용자가 댓글을 수정하고 확인하는 흐름을 붙잡아야 한다는 걸 알았다.

💡 "테스트는 코드의 양심이 아니라, 사용자가 기대한 약속을 자동으로 확인하는 장치다."

다음부터는 테스트를 추가할 때 "이 테스트가 어떤 위험을 줄이지?"를 먼저 써봐야겠다. 영철이 이제 면접에서 도구 이름보다 품질을 지키는 판단 기준을 말할 수 있을 것 같다.