Test 방식 재고

[eddy-kor-92]

• 현재: DB와 Riot api를 mocking 하여 테스트 코드 작성. 테스트 단위는 대상 객체의 개별 method를 유닛 테스트로 간주
• 문제: 테스트 하려는 method에서 사용하는 의존하는 mock의 method에 대한 answer를 미리 정의해야 테스트 코드가 제대로 실행됨.
  • 이는 제대로 동작하는 시나리오만 검증하게 될 가능성이 높다.
  • 예상치 못한 db나 네트워크 에러에 대한 대비가 안됨
  • 구현한 내용대로 테스트 코드도 짜기 때문에, 희망편으로만 작성하게 되는 경향
  • 또한, method의 세부 구현이 바뀔 때 사용하는 외부 의존 객체의 method가 달라질 수 있는데 그러면 테스트 코드도 고쳐야 함.
  • 리팩토링이나 bugfix 전후로 기존과 동일한 인터페이스를 제공하고 있는지를 확인하는 것이 테스트의 가장 큰 역할임
  • 근데 현재는 구현이 바뀌면 테스트 코드를 같이 수정하는 경우가 더 많기 때문에, 하위호환성 검증이 어렵다
  • 대부분의 테스트 코드가 상태 검증 (테스트 대상 메쏘드가 실행된 전후의 상태 변화를 검증)인데, 방식은 행위 검증의 형태
• 해결?
  • 실제 db와 riot api를 테스트 시에도 사용하는 편이 좋아보임
  • 문제는 riot api의 경우 daily로 key를 교체해줘야 한다는 점
  • 특히 github action을 통한 ci에서 문제가 될 수 있다.
  • 다만, PR을 올리는 시점에 올리는 사람이 적절히 application-test.yaml 같은 곳에 유효한 key를 넣어서 PR을 올린다면 PR에 대한 CI 파이프라인이 도는 동안은 잘 실행될 듯