[TIL] Jest를 이용해 테스트 코드를 작성해보자(2)

ㅜㅜ·2023년 3월 27일

TIL

Today I learn

목록 보기

75/77

Mock

목업이라는 말이 있듯이 Mock이라는 것은 진짜를 흉내낸 가짜를 말한다.
mock 함수라는 건 진짜를 흉내낸 가짜 함수라는 뜻이다.

테스트를 할 때 중요한 원칙 중 하나가 한 번의 테스트에서는 한 개의 대상만 테스트하자는 것인데,
의존성이 존재할 경우 내가 원하지 않는 테스트 결과가 나올 수 있다.

그러나 코드를 작성하다보면 특정 요소나 함수, 네트워크(네트워크 불안정 등)에 의존성이 생기기 마련인데,
이런 의존성을 제거한 상태로 원하는 기능만 테스트할 수 있게 만들어주는 기능이 mock이라고 할 수 있겠다.

mock reference

링크를 참고하면 mock과 관련된 다양한 API들을 참고할 수 있다.

mockImplementation : mock을 연결시켜준다

한 번의 테스트 후에 Mock을 초기화 해주자 (매 테스트가 실행되기 전)

jest의 config 파일에서 clearMocks를 true로 설정해주지 않는다면
beforeEach에 mock에 대한 .mockClear()를 추가로 입력해줄 필요가 있다.
그렇지 않으면 이전에 실행한 테스트들로 인해 다음 테스트가 영향을 받게 된다.

Staub

Mock은 진짜를 흉내내는 방식이지만 Stub는 진짜의 인터페이스를 충족하는, 실제로 구현된 코드라고 할 수 있음.
예를 들어 Stub로 만들어진 fetchItem이라는 함수를 사용했을 때 실제로 네트워크 통신을 하지 않더라도 필요한 데이터를 이미 반환해주고 있으므로 테스팅이 가능해진다.

아래처럼 Stub 클라이언트를 만들어주면 실제 프로덕트에는 실제 클라이언트를 사용하고, 테스트 시에는 Stub 클라이언트를 사용할 수 있게 된다.

class StubClient {
  async fetchItems() {
    return 
    [
      {name: 'pencil', price: '2000', sale: true}, 
     {name:'eraser', price:'300', sale: false}
    ]
  }

when mock ? stub ?

특정 상황에서 함수가 호출하는지 아닌지를 테스트할 때는 mock을 사용할 수 있다. => 어떤 행위의 검증 : 어떤 메소드의 리턴값으로 판단할 수 없는 경우, 특정 동작을 수행하는지를 확인.
staub는 어떤 상태의 검증에 사용 : 어떤 메소드가 수행된 다음 객체의 상태를 확인해 올바르게 동작했는지 확인.

느낀점

내가 작성한 코드를 남들이 좀 더 읽기 쉽게 하기 위한 방법으로 테스트 코드를 작성할 수 있을 것 같다. 정형화된 코드? 잘 정리된 코드? 그러니까 코드의 가독성을 높이는 방법에 대해 계속해서 고민하고 있는데, 테스트 코드를 잘 작성해보고 싶은 욕심이 생긴다.
Jest도 그렇고 최근 공부한 React-testing-library 문서들을 보면 사용할 수 있는 도구들이 많은데 내가 아직 제대로 몰라서 잘 사용을 못하는 느낌이다. 제대로 익히려면 프로젝트에 실제로 적용을 해보는 게 필요할듯. 완벽주의를 버리고 한 두개씩이라도 테스트 코드를 작성해봐야겠다.
테스트를 할 때는 의존성을 줄이는 게 정말 정말 중요하고, 무엇보다도 테스트 코드 뿐 아니라 기능 구현 코드를 작성할 때에도 의존성이 적도록 신경써서 코드를 작성해야겠다는 생각이 들었다. 이전에 메인 프로젝트를 할 때 멘토님께서 일정량 이상이면 코드를 분리하라는 이야기를 많이 하셨는데, 그게 일종의 의존성을 줄이는 효과도 있는 조언이 아니었을까.
테스트 코드 예시들을 보면 주로 클래스형 컴포넌트나 클래스, 인스턴스를 사용하는 것을 자주 볼 수 있다. 이전까지는 함수형 컴포넌트만 사용했었는데, 클래스형 컴포넌트가 사용되는 맥락이 궁금해진다. 사실 기술 면접 스터디를 하면서도 그런 이야기를 나눠본 적이 있는데, 함수형이 단순히 심플해서 입문자들이 많이 사용하기는 하지만, 클래스의 경우 기능이 훨씬 더 많다는 설명을 들은 적 있다. 아무래도 레벨 업! 하려면 클래스와도 친해져야 할 것 같은 걸? 🥹