프론트엔드·
토스 SLASH·
토스 SLASH·토스는 어떻게 광고 속에 게임을 넣었을까
토스가 광고 시스템을 자체 구축하면서 서드파티 SDK 대신 국제 광고 표준 MRAID를 직접 구현해 플레이어블 광고(앱 설치 전 게임 체험)를 지원한 과정이다. mraid.js 브릿지, 5중 렌더링 완료 신호, 보안 중심 설계, 앱 심사 없는 즉시 배포를 동시에 달성했다.
요약 이어보기#javascript#webview#sdk+2
프론트엔드·
카카오 스타일 (지그재그)·
카카오 스타일 (지그재그)·프론트엔드 테스트 자동화 전략 - 2. 요구사항 분석
프론트엔드 테스트 자동화 연재의 2편으로, 실제 테스트를 쓰기 전에 요구사항을 어떻게 뽑아낼지를 다룬다. 리팩터링 직전에 테스트를 쓰는 것을 시작점으로 권하고, 유저 스토리와 인수 조건을 거쳐 테스트 케이스를 만들고 컴포넌트에 분배하는 데까지 이어진다. 주소록이 있는 주문서 페이지를 예제로 삼는다.
핵심 포인트
- 테스트는 시간이 지나야 효용이 체감되므로 리팩터링 직전에 써서 이득을 바로 느끼게 하는 것이 시작으로 좋다.
- 리팩터링 전에 요구사항을 정리하면 오히려 테스트가 잘 실패하지 않는다. 요구사항을 명확히 이해한 만큼 버그가 줄기 때문이다.
- 개발 초기 기획서와 디자인은 후속 요구사항이 쌓여 유효하지 않은 경우가 많아, 배포된 코드와 화면을 보고 요구사항을 새로 쓰는 편이 낫다.
- 인수 조건은 서버나 외부 API, DB의 동작을 빼고 순수하게 사용자 관점으로 쓴다.
- 테스트 케이스는 직접 제어할 수 있는 영역에 맞춘다. DB에 저장됐는지가 아니라 저장 API가 호출됐는지를 본다.
- 테스트 케이스를 컴포넌트에 분배하는 일은 사실상 컴포넌트 설계를 정하는 일과 같다.
상세 정리
- 시작이 어려운 이유: 설정할 것이 많고 효과적인 작성 방법을 찾기도 어려운 데다 효용이 나중에야 체감되니 미루게 된다.
- 리팩터링과 함께 쓰는 이점 1: 기능의 요구사항이 정리되면서 버그가 줄어든다.
- 리팩터링과 함께 쓰는 이점 2: 나중에 코드를 다시 볼 때 테스트 코드가 요구사항 문서 역할을 한다.
- 리팩터링과 함께 쓰는 이점 3: 코드를 어떻게 고칠지 그림이 있는 상태에서 테스트를 쓰게 되므로 리팩터링에 내성이 있는 테스트, 즉 위양성을 피하는 방법을 고민하게 된다.
- 리팩터링과 함께 쓰는 이점 4: 요구사항을 벗어나는 변경이 생기면 테스트가 즉시 실패해 효용을 바로 본다.
- 예제 선정 이유: 주소록 기능은 여러 페이지에 걸쳐 동작하고 서버 API와 우편번호 API처럼 직접 제어할 수 없는 영역까지 끼어 있어 고민할 거리가 많다.
- 요구사항 갱신: 화면을 분석해 지금 상태 기준으로 요구사항을 다시 쓴다. 원본 기획서가 남아 있어도 후속 요구가 반영되며 초기와 크게 달라진 경우가 많기 때문이다.
- 유저 스토리: 구매자가 주소를 다시 입력하는 번거로움을 줄이려고 입력한 주소를 저장하고 불러오고 싶다는 식으로 제품이 주는 근본 가치를 문장으로 만든다. 나머지 요구사항은 여기서 파생된다.
- 인수 조건: 저장 버튼을 누르면 주소가 저장되고 이전 화면으로 이동한다처럼 사용자 관점의 조건을 쓴다.
- 프론트엔드로의 번역: 같은 조건도 프론트엔드에서는 DB 저장 여부가 아니라 저장 API 호출과 화면 이동으로 바꿔 적어야 한다.
- 부수 효과: 이렇게 케이스를 정리하면 시스템 간 상호작용과 의존성이 드러나고 백엔드에 필요한 API를 도출하는 데도 도움이 된다.
- 케이스 분배: 배송 불가 주소를 회색으로 표시하는 기능이라면 주소록 페이지가 아니라 주소 항목 컴포넌트가 스스로 조회하고 표시하도록 위임할 수 있다.
- 위임의 이득: 상위 컴포넌트는 하위 동작을 신뢰하고 관련 테스트를 건너뛴다. 컴포넌트를 재사용하면 검증도 함께 재사용되는 셈이다.
- 위임의 대가: 하위 컴포넌트의 요구사항이 테스트로 고정되면 그 동작을 바꾸기 어려워지고, 바꾸면 의존하는 상위 컴포넌트를 모두 다시 테스트해야 한다.
- 배치 기준: 테스트를 컴포넌트 동작의 문서로 본다면, 요구사항이 불명확하거나 설계가 흔들리는 경우에는 상위 컴포넌트에 두는 편이 낫다.
- 다음 편 예고: 유닛 테스트와 통합 테스트 코드를 실제로 쓰는 방법을 다룰 것이라고 밝힌다.
왜 읽나테스트를 쓰라는 말은 많이 들었는데 무엇을 검증할지 정하지 못하고 있다면, 화면에서 유저 스토리와 인수 조건을 거쳐 테스트 케이스로 내려가는 경로를 그대로 따라할 수 있다.
읽음 (0)
이 글과 비슷한
- 프론트엔드·
채널톡·RxJS로 우아하게 사이드 이펙트 통제하기
채널톡 고객용 SDK에서 boot→shutdown→boot 연속 호출 시 사이드 이펙트가 중첩되는 타이밍 버그를 RxJS 기반 구조 개편으로 해결한 사례다. 비동기 흐름 직렬화에 RxJS, 동기적 상태 관리에 Zustand를 도입해 타이밍 비결정성을 구조 수준에서 제거했다.
요약 이어보기#sdk#redux#rxjs+2 - 프론트엔드·
여기어때 (GC컴퍼니)·항공 프론트엔드 구축기 (7/10): 창구를 하나만 두었습니다
여기어때 항공 서비스 프론트엔드가 웹과 앱 웹뷰 두 환경에서 동일한 함수 호출로 동작하는 앱 브릿지 추상화 레이어를 설계한 과정을 다룬다. iOS·안드로이드 규약 차이와 "웹에 존재하지 않는 브릿지를 어떻게 호출하나"라는 문제를 단일 추상화 층으로 해결한 구현 사례다.
요약 이어보기#react#typescript#webview+2