문서

가치있는 테스트를 위한 전략과 구현

조민규 토스 · 토스 기술 블로그

AI 핵심 요약

테스트가 많고 느리며 구현에 강하게 결합되면 유지 비용이 커져 오히려 개발을 방해한다는 문제에서 출발해, 토스 팀은 가치가 높은 테스트를 선별하고 목적별로 나누는 전략을 세웠습니다. 핵심 비즈니스에는 도메인 정책 단위 테스트를, 사용자 여정에는 여러 계층을 아우르는 통합 인수 테스트를 적용해 테스트 수를 줄이면서 검증과 문서화 효과를 함께 얻고자 했습니다. 모의 객체 프레임워크 사용은 최소화하고 실제 객체를 우선했으며, 인수 테스트는 RestAssured와 커스텀 `@AcceptanceTest` 애노테이션으로 구성해 API 기준의 블랙박스 검증과 스프링 테스트 컨텍스트 재사용을 지원했습니다. 테스트 데이터는 SQL 파일 대신 JSON으로 관리하고 `TestExecutionListener`에서 실행 전 적재·실행 후 테이블 초기화를 처리해 테스트 격리를 구현했습니다.

테스트 작성 여부는 커버리지보다 핵심 기능의 변경 빈도와 버그 위험, 유지 비용을 기준으로 판단하세요.
도메인 정책은 단위 테스트로 검증하고, 경계값을 포함해 정책의 의미가 드러나도록 구성하세요.
모킹은 협력 객체의 구현 세부사항과 테스트를 결합할 수 있으므로, 가능한 경우 실제 객체를 우선 사용하세요.
인수 테스트는 API 명세를 기준으로 블랙박스 방식으로 작성하면 내부 리팩터링에 덜 민감해집니다.
테스트 데이터는 JSON으로 관리하고 실행 전후에 초기화하면 셋업 정보를 찾기 쉽고 테스트 간 격리를 유지할 수 있습니다.

소개

테스트에는 많은 장점이 있음에도 불구하고 현실에서는 테스트 코드 자체가 없는 경우가 다반사일 뿐만 아니라, 오히려 장애물이 되곤 하죠. 오늘은 토스에서 테스트 전략을 수립하고 구현한 과정을 자세히 살펴볼게요.

비슷한 학습 자료

문서 강연신/안재은/한가영

쉼 없이 도는 테스트, 사람이 어디까지 돌봐야 할까요? - 토스닥터(Toss Doctor)

문서 강연신/안재은/한가영

스스로 만들고 고치는 자동화, 토스닥터 V2를 다시 만든 이야기

소프트웨어 테스트 TDD

문서 이정성

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

문서 이정성

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

소프트웨어 테스트