[Spring] Mock 객체와 테스트코드 - 1

DEINGVELOP·2022년 9월 6일
0

Mock

: 실제 객체를 만들어 사용하기에는 시간, 비용 등의 cost가 높거나, 혹은 객체 서로간의 의존성이 강해 구현하기 힘들 경우 가짜 객체를 만들어 사용하는 방법

테스트, 그 중에서도 단위 테스트를 할 때에는 보통 한 번에 하나의 메소드만을 실행해본다.

단, 이때 이 메소드가 다른 DB나 네트워크 등의 제어하기 어려운 것들에 의존하고 있다면 문제가 될 수 있다. 즉, 해당 Flow가 아닌 다른 것들에 의존하고 있다면 단위테스트를 하기 어려운 환경이기 때문이다.

이런 경우에 Mock Object의 개념을 활용하여 테스트를 한다.


Mock객체가 더 효율적인 상황

  • 테스트 작성을 위한 환경 구축이 어려운 경우

  • 테스트가 특정 경우나 순간에 의존적인 경우

  • 테스트 시간이 오래 걸리는 경우

  • 개인 PC의 성능이나 서버의 성능 문제로 오래 걸릴 수 있는 경우, 시간을 단축하기 위해 사용한다.



Mock 관련 기본 개념


테스트 더블

: 테스트를 진행하기 어려운 경우, 이를 대신하여 테스트를 진행할 수 있도록 만들어주는 객체

  • Mock 객체와 유사한 의미를 가짐

  • 조금 더 상위 의미로 사용됨


Dummy Object (더미 객체)

  • 단순히 인스턴스화 될 수 있는 수준으로만 객체를 구현한 것

  • 인스턴스화 객체가 필요할 뿐, 해당 객체의 기능까지는 필요하지 않은 경우 사용


Test Stub (테스트 스텁)

: 더미 객체보다 조금 더 구현된 객체로, 더미 객체가 마치 실제로 동작하는 것처럼 보이게 만들어놓은 객체이다.

  • 객체의 특정 상태를 가정해서 만들어, 특정 값을 리턴해주거나 특정 메시지를 출력해주는 작업을 함

  • 특정 상태를 가정해서 하드코딩 된 형태 ➡ 로직에 따른 값의 변경은 테스트할 수 없음

  • 즉, stub : 어떤 행위가 호출되었을 때, 특정 값으로 리턴시켜주는 형태


Fake Object (페이크 객체)

: 여러 상태를 대표할 수 있도록 구현된 객체

➡ 실제 로직이 구현된 것처럼 보이게 한다.

  • 실제로 DB에 접속해서 비교할 때와 동일한 모양이 보이도록, 객체 내부에 구현할 수 있다.

  • 테스트케이스 작성을 위해, 다른 객체들과의 의존성을 제거하기 위해 사용

  • 페이크 객체를 만들 때에 복잡도로 인해 노력이 많이 들어갈 경우, 적절한 수준에서 구현하거나, Mock 프레임 워크를 사용함

  • 페이크 객체를 생성하기 위한 노력이 많이 필요할 경우, 실제 객체를 가져와 테스트


Test Spy (테스트 스파이)

  • 테스트에 사용되는 객체, 메소드의 사용 여부 및 정상 호출 여부를 기록하고, 요청시 알려주는 것

활용 방법

  • 테스트 더블로 구현된 객체에 자기 자신이 호출되었을 때, 확인이 필요한 부분을 기록하도록 구현한다.

  • 특정 테스트 메소드가 몇 번 호출되었는지 필요한 경우, 전역 변수로 카운트를 설정하고 특정 메소드 카운트를 올리는 부분을 추가한 후, 이 카운트를 가져오는 메소드를 추가한다.

  • '특정 메소드가 호출되었을 때, 또 다른 메소드가 실행되어야 한다' 등의 행위 기반 테스트가 필요한 경우 사용한다.


Mock Object (Mock 객체)

: 행위를 검증하기 위해 사용되는 객체

  • 수동으로 만들 수도 있고, 프레임워크를 통해 만들 수도 있다.

  • 행위 기반 테스트는 복잡도나 정확성 등 작성하기 어려운 부분이 많기 때문에, 상태 기반 테스트가 가능하다면 만들지 않는다.

  • Mock 객체

    • 테스트 더블 하위객체로써의 좁은 의미
    • 테스트 더블을 포함한 넓은 의미

    ➡ 총 2가지 의미로 사용될 수 있다.

💡 요약

  • Mock Object : 행위 검증(Behavior verification)에 사용
  • Stub상태 검증(State Verification)에 사용

Mock 사용시 유의사항

  • Mock 프레임워크가 꼭 필요한지 확인한다.

    • Mock 사용시, 테스트 케이스 유지에 복잡성이 더해지기 때문!
    • 의존성이 적은 구조 : Mock이 없는 것이 더욱 테스트 케이스 유지에 유리
  • 어떤 Moxk 프레임워크를 사용하느냐는 핵심 문제가 아니다.

  • Mock 객체는 Mock일 뿐이다.

  • 실제 객체로 작동을 해 보았을 때, 잘 작동하지 않을 수도 있다.

    • Mock 객체는 흉내만 내는 객체이기 때문!





참고자료

0개의 댓글