[항해 플러스 프론트엔드 5기] 7주차 회고

항해 플러스 프론트엔드 5기

이번 주차 목표 (프런트엔드 테스트 코드)

(1) 테스트의 필요성을 이해한다.

(2) 기본적인 테스트를 작성할 수 있다.

 

 

1. 고민했던 문제

- 통합 테스트를 진행하면서 mock 데이터를 생성하고 리스트에 반영하는 흐름이 자연스럽게 연결되었는지 판단하기 어려웠고, 실제로 테스트가 여러 번 실패하면서 디버깅에 시간을 많이 썼다.
하지만 그 과정에서 비동기 렌더링 타이밍, 상태 반영 시점 등을 파악하게 되면서 테스트에 대한 이해도가 확실히 높아졌다.

 

 

 

2. 시도 및 해결

- 이전에는 렌더링 안정화를 위해 waitFor를 사용했지만, 비동기 로직이 없는 경우에는 await act(() => null)처럼 최소한의 act 호출만으로도 충분하다는 점을 멘토링을 통해 알게 되었고, 이를 코드에 반영해 개선했다.

// 개선 전
await waitFor(() =>
  expect(screen.queryByText('검색 결과가 없습니다')).not.toBeInTheDocument()
);

// 개선 후
await act(() => null);
expect(screen.queryByText('검색 결과가 없습니다')).not.toBeInTheDocument();

- 컴포넌트 단위 테스트 및 통합 테스트의 중복을 줄이기 위해, 공통 setup 함수를 분리하여 관리하였다. 이를 통해 테스트 코드의 재사용성과 가독성을 높였다.

export const setup = (element: ReactElement): RenderResult & { user: UserEvent } => {
  const user = userEvent.setup();

  return { ...render(<ChakraProvider>{element}</ChakraProvider>), user }; 
};

ChakraProvider로 감싼 이유는, Chakra UI 컴포넌트들이 내부적으로 ThemeContext 등 Chakra의 Provider에 의존하기 때문이다. 실제 앱과 동일한 UI 환경을 구성하여 테스트 결과의 신뢰도를 높이기 위해 필수적으로 포함했다.

 

 

3. 개선해야 할 것

- ScheduleFormContainer에서 수정 대상 이벤트(editingEvent)를 상위에서 props로 받아야 했기 때문에, 이를 어떻게 상태 관리할지 고민이 많았다.
최종적으로는 상위에서 editingEvent와 setEditingEvent를 전달받고, 내부에서는 useEffect를 활용해 초기값을 설정했다.
초기화 로직은 editEvent라는 커스텀 함수로 분리하고 useCallback으로 감싸 재사용할 수 있게 구성했는데, 이 방식이 구조적으로 적절했는지에 대해서는 아직 고민 중이다.

- useEventForm의 상태가 많아지다 보니, 내부 로직을 values, setters, errors, handlers, 그리고 그 외 유틸 함수들로 나눠서 관리했다. 구조적으로는 나쁘지 않아 보이지만, 이렇게 나누는 방식이 과연 맞는지 확신은 없었다.
특히 resetForm이나 editEvent 같은 함수는 handlers로 봐야 할지, 별도 유틸로 분리해야 할지 경계가 모호하게 느껴졌고, 전체적으로 관리 방식에 대해 더 나은 방향이 있을지 고민이 됐다.

return {
  values: { title, date, startTime, ... },
  setters: { setTitle, setDate, setStartTime, ... },
  errors: { startTimeError, endTimeError },
  handlers: { handleStartTimeChange, handleEndTimeChange },
  editEvent,
  resetForm,
};

 

 

 

4. 알게된 것

- 처음에는 테스트 코드 작성이 어렵고 복잡하게 느껴졌지만, 직접 작성해보며 테스트의 흐름과 구조를 익힐 수 있었다. 특히 실무에서 테스트를 적용하고 싶었지만, 서비스 특성상 어떤 테스트 방식이 적절한지 판단하기 어려웠다. 이번 멘토링을 통해 기준점을 잡을 수 있었고, 단위 테스트(Unit Test)와 E2E/비주얼 테스트의 적용 대상을 구분하는 법을 익혔다.

• 예: 단순한 검수용 화면 → Unit Test 중심
• 사용자 흐름이 중요한 리스트/폼 화면 → E2E 혹은 비주얼 테스트 적합

- data-testid 속성을 활용해 테스트에서 원하는 요소를 안정적으로 선택할 수 있다는 점도 이번에 처음 알게 되었고, 앞으로는 테스트까지 고려한 마크업 설계가 중요하다는 것을 느꼈다.

- MSW를 활용한 API mocking을 처음으로 적용해보며 테스트 환경 구성에 대한 감을 익힐 수 있었다.

// msw 세팅 일부분
import { setupWorker } from 'msw/browser';

import { handlers } from './handlers';

export const worker = setupWorker(...handlers);

 

 

 

---

Keep : 현재 만족하고 계속 유지할 부분

미리미리 과제 진행하기

 

지난 주차에는 시간이 너무 부족해 아쉬움이 컸던 만큼, 이번 주차에는 일요일부터 과제를 시작했다. 초반엔 Hard 난이도를 도전할까 고민했지만 무리일 수 있다는 판단에 Medium을 선택했다. 하지만 수요일쯤 되니 세팅이나 구현 수준을 Hard처럼 맞추고 싶다는 생각이 들어 약간의 아쉬움이 남았다. 그래도 시간을 충분히 확보하니 심화 과제에 대해 더 깊이 고민할 수 있었고, 전반적으로 여유 있는 진행이 가능했다.

Problem : 개선이 필요하다고 생각하는 문제점

너무 쉬었다...😥

 

5월 초 연휴로 인해 1주일간의 방학이 있었고, 사이드 프로젝트나 개인적인 일들로 바쁘긴 했지만 상대적으로 코딩에 집중하지 못했다. 한 달 반 동안 긴장감 있게 지내다가 갑자기 여유가 생기니, 집중력이 확 떨어진 느낌이었다. 그 시간에 아티클을 열심히 읽고 블로그 정리라도 해둘 걸 하는 아쉬움이 남는다.

Try : 문제점을 해결하기 위해 시도해야 할 것

마음을 너무 놓지 말고, 일정한 긴장감을 유지하자

 

과제를 미루지 않은 점은 좋았지만, 마음이 너무 느슨해진 탓에 효율이 떨어진 순간들도 있었다. 그래도 이번 주에는 여유 있게 PR을 작성할 수 있었고, Medium 선택으로 BP를 받을 수 없다는 걸 알면서도, 궁금한 점들을 정리하고 질문하고 싶은 마음에 상세히 작성했다. 10주간의 항해가 끝나더라도, 이런 공부 습관은 계속 가져가고 싶다.