UseCase와 Repository 테스트 목적 정리

UseCase와 Repository 테스트 목적 정리

 

이 포스팅은 현재 기준으로 내가 테스트 코드를 작성할 때 가지는 일종의 가이드라인. 

성장하면서 바뀔 수도 있음.

 

글의 순서

• UseCase 테스트 목적
• Repository 테스트 목적
• Repository 테스트 하기
• SearchSubwayUseCaseTests 실패 후 로직 보완

 

안드로이드 공식 앱 아키텍처 가이드를 확인하면서 UseCase 영역에 해당하는 Domain이 Optional로 되어 있음을 확인할 수 있었음.

개인 경험에 의하면 실제로 UseCase에서 특별한 처리 없이 사실상 래핑에만 해당하는 경우도 많긴 함.

 

일반적인 상황에서는 Domain Optional 이어도 나쁘지 않겠지만, 기능이 하나 둘 추가되면서 Repository가 두꺼워지고 결국은 UseCase를 분리하는 과정에서 오는 피로를 생각하면 처음에 분리해두는 것도 좋다고 생각.

 

테스트 상황에서 UseCase와 Repository 테스트의 목적은 각각의 역할과 책임에 따라 다름.

 

UseCase 테스트 목적

• 비즈니스 로직 검증: 내가 작성한 로직이 제대로 작성되었는지 검증
  • 예시: 캐싱 로직을 도입했으나, 캐싱 값 갱신을 실수로 누락
• 입력 및 출력 검증: 주어진 입력에 대해 예상된(올바른) 결과가 나오는지 검증
  • 예시: 특정 실패하는 상황을 입력으로 주었을 때, 해당 상황에 대한 정확한 에러가 나타나는지 확인
• 상태 관리 검증: 상태 혹은 캐싱 값이 올바른지 검증
  • 예시: 캐싱되어 있는 값이 정확한지 확인
• 통합 테스트: 주입받은 의존성 등과 전체 흐름이 올바르게 동작하는지 검증.
  • 예시: 시나리오 테스트

 

UseCase 테스트는 아래 포스팅에서 확인 가능

https://rldd.tistory.com/643

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

Repository 테스트 목적

• API 통신 검증: API와 통신할 때 실제로 요청한 값에 대해 제대로 응답을 받는지 검증
  • 예시: 요청에 대해 호출이 정확하게 되는지
• 에러 처리 검증: API 호출에 대한 실패 케이스 검증
  • 예시: 타임아웃, 서버에서 내려주는 실패 등 검증
• 데이터 검증: 데이터베이스 CRUD가 제대로 되는지 검증
  • 예시: DB가 올바르게 동작하는지 검증

 

Repository 테스트 하기

이전에 작업했던 사이드 프로젝트에서 지하철 검색 기능을 통해 작성

 

레포지토리 테스트 코드 전체

 

 

 

서버 통신이 잘 되는걸 확인하기 위한 테스트

고민 포인트

• 데이터 응답 값이 향후 서비스가 운영됨에 따라서 서버가 내려주는 값이 달라질 탠데, 어떻게 검증하는 것이 좋을지

 

테스트 코드

 

 

서버 통신이 실패시 에러를 잘 뱉어내는지 테스트

고민 포인트

• 에러 메시지 나타낼 때 명령형으로 나타내는 것과 한글 쓸 지 영어 쓸지에 대한 고민

 

서버 통신 실패시 케이스

 

 

 

 

 

(참고)

 

https://developer.android.com/topic/architecture?hl=ko&_gl=1*1hv0qkx*_up*MQ..*_ga*MzEzMDI0NjUwLjE3MjY4MjcyNjY.*_ga_6HH9YJMN9M*MTcyNjgyNzI2Ni4xLjAuMTcyNjgyNzI3OS4wLjAuMTE0ODE3MTg0OQ

앱 아키텍처 가이드  |  Android Developers