문을 없애고 테스트하기: 프론트엔드 코드 품질을 올리는 리팩터링 관점

테스트가 잘 안 써지는 코드는 대개 팀의 의지가 부족해서가 아니라, 코드 구조가 테스트를 거부하고 있기 때문인 경우가 많습니다.

실무에서 자주 만나는 패턴은 이렇습니다.

• 한 함수에 조건문이 너무 많다
• UI 상태, API 호출, 도메인 규칙이 뒤섞여 있다
• 테스트를 쓰려면 모킹이 과도하게 필요하다

이럴 때 필요한 건 테스트 도구 교체가 아니라, 분기(문)를 줄이고 책임을 분리하는 리팩터링입니다.

왜 분기가 많으면 테스트가 어려워질까?

분기가 많아질수록 테스트 케이스 수는 급격히 늘어납니다.

예를 들어 if 조건 3개만 있어도 경로는 금방 폭증해요. 그리고 분기 안에서 외부 의존성(API, storage, router)까지 호출하면, 단위 테스트는 사실상 통합 테스트처럼 무거워집니다.

핵심은:

테스트의 적은 “테스트 코드”가 아니라 “변경에 취약한 설계”다.

리팩터링 기본 전략

1) 조건문을 도메인 함수로 이동

UI 컴포넌트 내부의 분기를 도메인 함수로 분리하면, 로직 테스트가 쉬워지고 UI는 표현에 집중할 수 있습니다.

// before: 컴포넌트 내부에 규칙이 섞임
if (user.role === 'admin' && item.status !== 'archived') {
  // ...
}
 
// after: 도메인 함수로 추출
if (canEditItem(user, item)) {
  // ...
}

2) 부수효과와 순수 로직 분리

• 순수 로직: 입력 → 출력 (테스트 쉬움)
• 부수효과: 네트워크/스토리지/라우팅 (경계로 밀어내기)

3) 상태 전이를 명시적으로 모델링

복잡한 UI 상태는 “흐름”으로 다루면 테스트가 쉬워집니다.

• idle -> loading -> success | error
• 분산된 boolean보다 상태 머신/유니온 타입이 안전

실무에서 바로 쓰는 점검표

• 이 함수는 UI 렌더링과 비즈니스 규칙을 동시에 처리하는가?
• 조건문이 2단 이상 중첩되어 있는가?
• 테스트 작성 시 mock이 3개 이상 필요한가?
• 실패 케이스를 자연스럽게 재현할 수 있는가?

3개 이상 해당하면 리팩터링 우선순위를 올리는 게 좋습니다.

면접에서 이렇게 말하면 좋다

• “테스트 커버리지 숫자보다, 변경 시 신뢰도를 높이는 구조를 먼저 만듭니다.”
• “조건문을 줄이기 위해 도메인 함수 추출과 상태 전이 모델링을 사용합니다.”
• “테스트가 어려운 코드를 발견하면 테스트 코드를 억지로 늘리기보다 설계를 먼저 고칩니다.”

이 답변은 단순히 테스트 툴 사용 경험보다 품질을 설계 관점에서 이해한다는 인상을 줍니다.

포트폴리오에 남길 수 있는 형태

프로젝트 문서에 아래 3가지만 넣어도 강합니다.

1. Before/After 코드(짧은 스니펫)
2. 리팩터링 의도(무엇을 줄이고 분리했는지)
3. 결과(테스트 작성 난이도, 유지보수 체감 개선)

수치가 없더라도 “변경 리스크 감소”를 재현 가능한 사례로 보여주면 충분히 경쟁력이 있습니다.

마무리

프론트엔드 품질 개선은 lint 규칙을 늘리는 것으로 끝나지 않습니다.

• 분기를 줄이고
• 책임을 나누고
• 테스트 가능한 경계를 만드는 것

이 3개를 반복하면 코드와 팀 생산성이 같이 좋아집니다.

그리고 이 관점은 이직 면접에서도 강력한 차별점이 됩니다. “기능 구현”을 넘어서 품질을 설계하는 개발자로 보이게 하니까요.