Unit Test and Jest

나는 2년정도의 QA를 가지고 있다, 그렇기 때문에 테스트에 대한 중요성은 잘 알고 있고 테스팅과 관련된 자격증까지 보유하고 있다.

하지만, 개발자로 업무를 전향한 후에는 테스트 코드 작성에 있어서 사실 회의감이 들었다 이유인즉, 경험했던 환경이 스타트업이기도 했고 하루빨리 흑자 전환을 할 수 있는 캐시카우의 모델을 찾는 것이 중심을 가져가며, 우리가 해결하고 싶었던 문제들에 대한 서비스를 빠르게 개발하고 시장의 반응을 보는 것이 가장 최우선이었다.

 

그렇기에 회사에서 제공하는 리소스는 적을 수 밖에 없고, 심지어 개발자들의 오버 엔지니어링이 들어가기에 기피하는 분들도 있기 마련이다. 더 작은 회사들은 QA의 테스팅을 기획자나 디자이너가 챙기는 일도 부지기수로 알고 있다(물론 내가 경험한 곳은 전문적인 QA 팀이 있었다)

 

그런데 그 와중에 테스트 코드 작성이라.. 물론 중요하고 필요한 작업임은 알고 있지만 우선순위를 두면 대부분의 스타트업에서는 후위에 있다고 생각을 한다 하지만 요번에 프론트엔드에서 Unit Test를 수월하게 할 수 있는 프레임워크인 Jest를 예시로 실제로 사용을 해보고, 내가 느꼈던 부분과 공감이 되는 부분 그리고 공감이 되지 않던 부분에 있어 포스팅을 해보려고 하며 요번 블로깅은 테스트의 종류들에 대한 정의, 테스트의 해석 등에 대한 작성은 아니고, 오롯이 내가 잠깐이지만 사용해 보고 느꼈던 부분과 QA였음에도 이전의 모습은 잃어버리고 개발자 마인드로 장착이 돼버린 바보 같을지 모르는 내 생각의 해석이다.

 

먼저 나는 테스트를 하지 말자고 하는 것이 아니다, 테스트 없이 배포하는 서비스는 어디 있겠는가.. 테스트가 안된 서비스의 경우 곳 유저 이탈로 이어지고 매출과 연관이 있기에  테스트는 필수적이라고 생각하며 글을 시작한다.

 

 

 

Unit Test

테스팅 종류는 여러 가지다 그중에 Unit Test에 대한 이야기를 해 볼 것이다.
단위 테스트(Unit Test)는 요번에 내가 겪어본 테스팅 기법이다, 테스팅의 기법은 다양하며 단위 테스트의 특징은 독립적으로 진행되는 하나의 작은 단위 테스트라고 볼 수 있다. 그것이 UI의 노출이라든지 아니면 메소드가 input에 대한 return의 결과가 설계대로 작동하는지 등 다양하게 확인이 가능하다. 테스팅 코드를 작성한다고 실무에서 작업이 들어가면 대부분 Unit Test를 하기 위해 코드를 작성한다고 이해하면 될 것 같다. 나는 필수적이진 않지만 이 Unit Test를 더 좋은 서비스를 만들고자 하는 개발자들의 긍정적인 마음의 노력이라고 생각한다.

 

사실 테스트 코드 작성이 아니더라도 view의 경우는 직접 보면 되고 비즈니스 로직으로 사용되는 메소드들의 경우 메소드 내의 적절한 if 문으로 분기 처리와 타입 체크 등으로 다 지켜지면 되는 부분이 아닐까 생각을 하는데 왜 따로 코드를 작성을 해야 할까 아래를 확인을 해보자

function add(a: number, b: number) {
  return a + b;
}

it("add 테스트", () => {
  expect(add(1, 3)).toBe(4);
});

 

위의 경우를 보면 add라는 간단한 메소드가 있고 그것에 해당하는 테스트 코드이다.

이러한 쉬운 로직의 코드에서는 과연 테스트 코드가 필요할까? 다음을 알아보자.

 

it("퀴즈 정답을 클릭할때에 문구 스타일 정상 변경되는지 확인", () => {
    const { getByText } = render(
      <RecoilRoot
        initializeState={(snapshot) => snapshot.set(quizItemList, initialData)}
      >
        <QuizContent />
      </RecoilRoot>
    );
    fireEvent.click(getByText("1. A"));
    expect(getByText("1. A").classList.contains("answerButtonExcellent")).toBe(
      true
    );
  });

 

 

 

요번엔 실제로 내가 사용했던 테스팅 코드이다, 퀴즈가 있고 답안을 클릭해서 정답인 경우 스타일이 변경되는지 확인하는 코드이다.
해당 코드를 보면 mock data로 RecoilRoot에 넣어주고 1. A 라고 적혀있는 텍스트의 버튼의 event가 발생할 경우 버튼이 바뀌게 된다, 해당 버튼의 경우에는 정답이어야만 스타일이 바뀌는 분기 처리가 되었기 때문에 해당 분기 처리 또한 정상적으로 통과가 된 거라고 볼 수 있다. view와 관련된 테스트 코드라고 볼 수 있다.

 

한 가지 예제를 더 확인 해보자

it("Start 버튼 클릭 시 초기화 및 페이지 이동이 일어나는지 확인을 함", async () => {
    fetchMock.mockResponseOnce(JSON.stringify({ results: [] }));

    render(
      <RecoilRoot>
        <ActiveButton type="Main" />
      </RecoilRoot>
    );

    await act(async () => {
      fireEvent.click(screen.getByText("Start"));
    });

    expect(require("next/navigation").useRouter().push).toHaveBeenCalledWith(
      "/quiz"
    );
  });

 

위와 같은 코드는 특정 fetch가 이뤄지고 페이지가 이동하게 되는 경우가 있다면 정상적으로 페이지 이동이 되었는가에 대한 질문이다.

처음 써보는 테스트 코드이다 보니깐 완벽하지는 않지만 페이지 이동까지 확인이 가능하다는 부분에서 조금 놀라웠다.

 

 

여태 3가지의 경우를 알아봤다

 

1. 쉬운 메소드의 테스트

2. 스타일 및 컴포넌트 변경 테스트

3. 통신 테스트

 

이렇게 다양하게 테스트를 할 수 있다는 점에서는 굉장히 흥미로웠지만 아직 나에게는 많이 와닿지는 않았다, 왜냐하면 테스트 코드 작성 리소스에 비해 얻어 가는 결과가 충분하지 않다고 생각을 하기 때문인 것 같다 (물론 처음 써보는 테스트 코드이다 보니 그렇게 생각하는 걸 수도 있다..)

 

요번 블로깅을 하면서 현업에서 훨씬 복잡한 예제들과 테스트 코드의 다양한 도입들도 확인해 보았고, 테스팅에 대해 어떻게 생각하는지 다양한 글도 확인을 했었다.

 

그리고 내 생각은 이렇게 들었다.

 

테스트 코드 작성은 필수가 아니다, 서비스 배포 일정도 빠듯하고 큰 프로젝트의 경우 테스트의 영역을 다 채워 넣을 수 없을 것 같다.

하지만 작성할 줄 알아야 하고, 그리고 다양한 테스트 방법으로 서비스를 더 신뢰 있게 할 수 있고 테스트가 가지는 중요성을 이해할 줄 알아야 한다고 생각한다 시장에서 요구하는 제품의 퀄리티는 날이 갈수록 엄격해지고 있고, 웹 기술은 걷잡을 수 없을 정도로 빨라지고 있는 것 같다 (Next13 버전에서 1년도 채 안 지난 시점에 14 버전이 나와 버린 것만 해도 알 수 있다) 그렇기에 점점 프론트의 영역도 확장이 되는 만큼 할 줄 몰라 안 하는 것과 할 줄도 알고 필요성은 알지만 선택적으로 안 하는 것은 천지차이라는 것을 요번 테스트 작성에 있어서 많이 느꼈던 것 같다.

 

 

 

장점으로는 이렇게 생각한다.

1. 결국 내가 작성한 코드가 "의도"대로 동작을 하고 있다고 확신을 할 수 있다.

2. 작동 방식의 변경이 없다면 테스트로 기둥을 세운 뒤에 추가 로직의 수정이 있어도 테스트의 방식대로 코드를 구현하게 된다 (TDD 느낌이 나는군..)

3. 독립적으로 딱 특정 부분에 대해 테스트를 진행하기에 추후에 코드 리팩토링이 있어도 문제를 빠르게 확인이 가능하다.

 

단점으로는 이렇게 생각한다.
1. 모킹에 의존할 수밖에 없게 되는 경우에 이게 정확하게 테스트를 하고 있다고 볼 수 있을까?
2. 작은 단위의 테스트이기 때문에 사용하고 있는 api와 라이브러리의 변경이 있다면 수정해 줘야 하는 부분이 많을 것 같다.
3. 기능의 변화가 있을 경우에 예상치 못한 테스트의 코드도 수정해야 할 수 있다. 

---

해당 블로그는 공부한 내용의 기록으로 중점이 맞춰져있습니다.

스스로 어떻게 받아들이고 있는지에 대한 주관적인 견해가 많이 들어가 있습니다.
그렇기에 다소 설명이 부족하고 다른 방향으로 해석할 수 있는 여지가 있습니다.

우연찮게 지나가다가 발견하신 글이라면 다양한 의견 감사하게 받아들이겠습니다.