문서

달리는 기차의 바퀴 교체하기 2. Restructuring

한재엽 토스 · 토스 기술 블로그

AI 핵심 요약

운영 중인 프론트엔드 제품을 재구조화하면서 테스트를 신뢰할 수 있도록 리팩토링 내성을 우선 개선했다. 실행 순서에 의존하는 공유 상태를 제거하고, 내부 구현 대신 기능을 검증하며, API Client·Storage·Logging 같은 외부 의존성을 식별해 Context API 기반으로 주입했다. 그 결과 테스트가 독립적이고 이해하기 쉬워져 기능 변경과 리팩토링을 검증하는 문서로 활용할 수 있게 됐다. 다만 Provider 중첩과 런타임 오류 검증은 남은 과제로, 의존성 관리 체계와 E2E 테스트 도입을 검토하고 있다.

테스트 케이스는 공유 상태와 mock을 격리해 실행 순서와 병렬 실행에 영향을 받지 않도록 한다.
컴포넌트 테스트는 파일 경로나 hook 같은 세부 구현보다 사용자에게 드러나는 기능을 검증한다.
외부 의존성의 경계를 제품 관점에서 정하고, API·Storage·Logging 등을 추상화해 주입한다.
의존성 주입은 Context API로 시작할 수 있지만 Provider 중첩이 늘어나는 비용도 고려한다.
단위·통합 테스트가 놓치는 런타임 오류를 보완하려면 E2E 테스트의 비용과 효과를 따져야 한다.

소개

이미 운영 중인 제품을 전부 갈아엎고 다시 만드는 경험을 하기는 어려운데요. 운 좋게 팀 내 공감대가 형성되어 여러 팀원과 하나의 제품을 온전히 개선해 볼 수 있었어요. 앞선 내용에 이어서 이 글에서는 구체적으로 어떻게 개선했는지 소개할게요.

비슷한 학습 자료

문서 이정성

토스의 속도와 품질, 상용 도구로 충분한가 — 토션(Tossion)

문서 이정성

안녕하세요. 토스 QA Platform 팀 리더 이정성입니다. 지난 글에서 저희가 누구이고 무엇을 만들어 왔는지 짧게 소개해 드렸는데요. 오늘은 그 첫 번째 이야기, 저희만의 플랫폼 토션(Tossion)을 소개합니다. "이 기능, 지난번에 테스트 결과 어땠었죠?" QA라면 릴리즈 직전에 이 질문을 한 번쯤 받아 보셨을 겁니다. 저희도 받았고, 답을 드리는 데 시간이 걸리곤 했습니다. 자동화 테스트(Automation Test) 결과, 매뉴얼 테스트(Manual Test) 결과와 테스트 케이스(Test Case) 그리고 각 테스트의 ...

소프트웨어 테스트