iOS프로젝트/🥊 funch
지하철 검색 기능에 캐싱 로직 도입하기
lgvv
2024. 9. 20. 18:49
지하철 검색 기능에 캐싱 로직 도입하기
지하철 검색 로직에 캐싱 로직을 도입.
글의 순서
- SearchSubwayUseCase 개선
- SearchSubwayUseCase 테스트를 위한 Stub 객체 만들기
- SearchSubwayUseCaseTests 캐싱 로직 동작 검증 코드
- SearchSubwayUseCaseTests 실패 후 로직 보완
지하철 검색 로직은 사용자가 키보드를 통해 검색어를 입력할 때 throttle을 활용해 약간의 시간을 두어 검색을 실행.
- 여기까지는 우리가 일반적으로 사용하는 검색 로직.
동일한 값에 대해 서버 요청을 줄이고, 동일한 결과값을 더 빨리 제공할 수 있으므로 이점은 확실.
SearchSubwayUseCase 개선
기존에 Combine을 활용해서 처리하고 있었는데, cache 프로퍼티를 두어 기능 개선.
매우 간단히 처리할 수 있음.
SearchSubwayUseCase 테스트를 위한 Stub 객체 만들기
검색 캐싱 로직을 만들었으니 테스트 코드 작성 통해 검증
- 1. UseCase의 테스트 코드 작성을 위해 Repository 주입이 필요
- 2. 캐싱 로직 검증을 위해 실제 동작하는 Repository는 필요 없으므로 테스트 목적을 위한 Stub 제작
Stub 초기화 및 결과 값을 임의로 설정할 수 있도록 함수 추가
이후 Stub을 테스트 대상인 sut 구성
SearchSubwayUseCaseTests 캐싱 로직 동작 검증 코드
테스트 주안점
- BDD 기반으로 작성할 것.
- 시나리오를 잘 담아낼 것.
- 빈틈 없지만, 너무 복잡하지 않을 것.
고민 포인트
- cache 프로퍼티의 접근제어자가 `private`으로 테스트 코드에서 접근할 수 없는 부분
- 대안 1: 비공식 api인 @_spi 사용하기
- 대안 2: `private(set)`으로 바꾸기
- 선택: 대안 2
- 사유: @_spi를 사용할 경우 외부 모듈에 노출되는 문제가 있어서 그냥 `Feature` 모듈에서 테스트가 목적이라 `private(set)`을채택
SearchSubwayUseCaseTests 실패 후 로직 보완
처음 테스트 코드 동작시 실패 확인
- 사유: 응답 성공 시, 캐시 프로퍼티 업데이트하는 로직 누락.
잘못 작성한 캐싱 로직 코드
위의 완성된 코드와 비교해서 볼 것
레포지토리 테스트는 아래의 링크에서 확인 가능