지하철 검색 기능에 캐싱 로직 도입하기

지하철 검색 기능에 캐싱 로직 도입하기

 

지하철 검색 로직에 캐싱 로직을 도입.

 

글의 순서

• SearchSubwayUseCase 개선
• SearchSubwayUseCase 테스트를 위한 Stub 객체 만들기
• SearchSubwayUseCaseTests 캐싱 로직 동작 검증 코드
• SearchSubwayUseCaseTests 실패 후 로직 보완

 

 

지하철 검색 로직은 사용자가 키보드를 통해 검색어를 입력할 때 throttle을 활용해 약간의 시간을 두어 검색을 실행.

• 여기까지는 우리가 일반적으로 사용하는 검색 로직.

 

동일한 값에 대해 서버 요청을 줄이고, 동일한 결과값을 더 빨리 제공할 수 있으므로 이점은 확실.

 

SearchSubwayUseCase 개선

기존에 Combine을 활용해서 처리하고 있었는데, cache 프로퍼티를 두어 기능 개선.

매우 간단히 처리할 수 있음.

 

완성된 캐싱 로직 도입 코드

 

 

 

SearchSubwayUseCase 테스트를 위한 Stub 객체 만들기

검색 캐싱 로직을 만들었으니 테스트 코드 작성 통해 검증

 

• 1. UseCase의 테스트 코드 작성을 위해 Repository 주입이 필요
• 2. 캐싱 로직 검증을 위해 실제 동작하는 Repository는 필요 없으므로 테스트 목적을 위한 Stub 제작

테스트를 위한 Stub 제작

 

 

Stub 초기화 및 결과 값을 임의로 설정할 수 있도록 함수 추가

이후 Stub을 테스트 대상인 sut 구성

 

Stub을 통한 테스트 목적 대상 sut 구성

 

 

SearchSubwayUseCaseTests 캐싱 로직 동작 검증 코드

테스트 주안점

• BDD 기반으로 작성할 것.
• 시나리오를 잘 담아낼 것.
• 빈틈 없지만, 너무 복잡하지 않을 것.

고민 포인트

• cache 프로퍼티의 접근제어자가 `private`으로 테스트 코드에서 접근할 수 없는 부분
• 대안 1: 비공식 api인 @_spi 사용하기
• 대안 2: `private(set)`으로 바꾸기
  
  • 선택: 대안 2
  • 사유: @_spi를 사용할 경우 외부 모듈에 노출되는 문제가 있어서 그냥 `Feature` 모듈에서 테스트가 목적이라 `private(set)`을채택

 

전체 테스트 코드

 

 

 

SearchSubwayUseCaseTests 실패 후 로직 보완

 

처음 테스트 코드 동작시 실패 확인

• 사유: 응답 성공 시, 캐시 프로퍼티 업데이트하는 로직 누락.

테스트 실패

 

 

잘못 작성한 캐싱 로직 코드

위의 완성된 코드와 비교해서 볼 것

 

처음에 잘못 작성한 캐싱 로직

 

 

 

레포지토리 테스트는 아래의 링크에서 확인 가능

 

https://rldd.tistory.com/644

UseCase와 Repository 테스트 목적 정리