콘텐츠로 이동

2022 09 13

2022-09-13

Primary 어노테이션

  • 문제상황
    • 테스트에서 쓸 URL generator 빈을 따로 생성해 Primary 어노테이션을 붙임
      • 우선 테스트에서 작성한 Bean은 테스트에서만 동작하기 때문에 문제가 없을것이라고 판단하였음
    • 그런데 해당 Bean이 다른 테스트에도 영향을 줌
      • 다른 테스트는 원래 Production의 기존 Bean이 필요한 상태...
  • 해결 방법
    1. KasService에 endpoint setter를 만든다.
      • 엔드포인트를 동적으로 변경할 수 있도록 지원
      • 장점
        • 동적으로 객체 교환 가능
      • 단점
        • 테스트를 위한 코드가 프로덕션에 낀다는 것
    2. KasService를 Test에서 config 하는 파일 작성
      • @TestConfiguration
      • 장점
        • 가장 깔끔! 테스트에서 쓰일 설정을 하나하나 여기서 재 설정해주고
        • 스프링 환경의 DI, IoC 혜택을 그대로 누릴 수 있음
    3. Value 어노테이션이 붙은 값의 setter 작성
      • Value 값을 동적으로 변경할 수 있도록 지원
      • 장점
        • 매핑이 제대로 안된거... 극복할 수 있음
      • 단점
        • 테스트를 위한 코드가 프로덕션에 낀다는 것

TestConfiguration

  • 참고: https://meetup.toast.com/posts/124
  • 기존 정의된 Configuration을 커스터마이징 하고자 하는 경우 TestConfiguration을 통해 사용 가능
  • ComponentScan 과정에서 TestConfiguration 생성
    • 해당 자신이 속한 테스트 실행될 시 정의된 빈을 생성하여 등록될 것
  • 직접 TestConfiguration을 추가해줘야해
    • @Import를 사용하자

When to Mock

  • 모킹을 안한다면 단점
    • 테스트 매우 느릴 것
    • 웹서버, DB, 서비스, 네트워크 싹다 느릴것
    • 커버리지 낮아질 것
      • 파일 삭제나 이런거 모킹 없으면 구현하기 위험할 수도
  • 너무 많은 모킹의 단점
    • 모킹 시스템 중 몇 개는 리플렉션에 너무 많이 의존 => 느림
    • 모킹한 클래스가 다른 모킹 객체를 반환할수도 => 모든 데이터 패스를 모킹할래?
      1. 너무 복잡해짐
      2. 너무 결합도가 높아져서 변경에 취약해짐
  • 경험에 의한 인사이트
    • 아키텍쳐의 바운더리를 모킹하되, 바운더리 안을 모킹하지 말 것
    • DB, 웹서버, 외부 서비스를 모킹하는 것은 좋다
      1. 테스트 빨라짐
      2. 테스트가 실패에 민감하지 않아
      3. 모킹으로 실패 시나리오 쉽게 작성 가능
      4. 유한상태 머신의 모든 바운더리 패쓰 테스트 가능
      5. 모킹한 객체가 모킹한거 반환하면 안돼!
    • 이를 통해 아키텍쳐 바운더리가 무엇인지 고민해볼 수 있음
      • 다형성 인터페이스 등
    • 의존성 등에 대한 고민 => 좋은 소프트웨어 디자

OpenFeign