['프런트엔드 개발을 위한 테스트입문' 서평] - 테스트를 '잘' 설계하는 법?

BRINCE·2024년 6월 30일
0

우리 제품엔 어떤 테스트가 가장 중요할까? 🤔

프론트엔드에서의 테스트 환경 '구축'은 굉장히 쉽습니다.

하지만 어떻게 테스트를 작성할지, 어디서부터 어디까지 테스트의 범위에 포함시킬지
혹은 하나의 테스트 케이스를 작성할 때 세부적인 코드에 대한 설계를 어떻게 진행해야 할지..
고민해야 할 부분들이 굉장히 많습니다.

특히나 프론트엔드 테스트에 대한 기본적인 예제는 굉장히 많지만, 잘 운영되고 있는 큰 서비스에서는 어떻게 테스트 환경을 구축했는지에 대한 레퍼런스는 찾아볼 수 없었습니다.

안그래도 테스트에 대한 고민을 너무나 많이 해왔던 터라 자연스럽게 참고해볼만한 책이나 자료를 찾고 있었습니다.

그러다 제이펍의 '프런트엔드 개발을 위한 테스트입문' 서평단 모집 이벤트 글을 보게 되었습니다.

개발 환경의 변화와는 대조적으로 테스트 코드 작성을 어려워하는 개발자가 많아요. 게다가 프런트엔드 테스트는 UI 컴포넌트 테스트, 시각적 회귀 테스트, 스토리북, E2E 테스트 등 테스트 방법이 너무 많아서 언제, 어떤 테스트가 필요한지 판단하는 것이 쉽지 않으니까요 ... 생략

당장 테스트 자동화에 대해서 고민해보는 자리를 만들어보고자 사내에서 스터디도 진행하고 있었고 몇달동안 PoC 를 진행하고 있었기 때문에 이 책이 적절한 해답.. 까진 아니더라도 방안을 제시해줄 수 있을거라는 확신이 들게 되었습니다.

그렇게 운 좋게 서평단 이벤트에 당첨되어 서평을 작성하게 되었습니다 :)


책 소개

보통 아무리 잘 정리된 가이드가 존재한다고 해도, 서비스마다 적용할 수 있는 범위가 다를거라고 생각됩니다.

하지만 이러한 고민을 조금이라도 줄여줄 수 있도록 여러개의 테스트 모델에 대한 설명과 예제가 포함되어 있고
각 테스트별로 하나의 기능에 대해 어떻게 테스트를 진행할 수 있을지에 대해서 예제 코드와 이미지로 친절하게 설명해줍니다.

그리고 무엇보다 중요한건 이 책은 23년 4월에 쓰여져 비교적 프론트엔드의 최신 트랜드를 반영한 테스팅 가이드라고 볼 수 있습니다.

바이블이라 칭해지는 책들이 몇년 혹은 몇십년 전에 출판되어 레거시 코드를 예제로 사용하고 있는 것들을 생각해보면 참고하기 좋은 책이란 생각이 들기도 했습니다.

저자인 요시이 다케후미는 일본에서 활동중인 개발자인데, 저자의 블로그에 읽기 좋은 글들이 굉장히 많습니다.
솔직히 책을 읽기 전에 일본의 프론트엔드 개발씬에 대해서 생각해본적이 없었습니다.
저자가 쓴 글 외에 zenn 에 올라온 여러 글들을 읽어봤는데.. 역시 공부해야 할 건 많고 세상엔 괴물이 많네요.
https://zenn.dev/takepepe

  1. 프론트엔드 에서의 테스트 자동화 및 라이브러리, 프레임워크 종류에 대한 설명
    a. 테스트를 작성해야 하는 이유
    b. 실무에서의 테스트 자동화
  2. 테스트 방법과 전략
    a. 테스트 범위에 대한 설명
    b. 테스트 전략 모델과 계획
  3. 각 테스트 범위별 환경 설정부터 실행까지의 예제 코드
    a. 단위 테스트
    b. 통합 테스트
    c. UI 컴포넌트 테스트
    d. E2E 테스트

크게 이정도의 범위와 순서로 진행이 됩니다.

팀원들을 설득하는 방법

개발을 하다보면 아무리 좋은 기술에 대한 글을 읽게 되더라도 정작 내가 개발하고 있는 제품과 해당 기술이 잘 맞을지에 대한 고민을 계속 하게 됩니다.

이러한 고민을 조금이라도 덜어줄 수 있는 내용을 많이 포함하고 있습니다.

이 책은 테스트 코드를 작성하고 실행하는 법에서 한단계 더 나아가 어떻게 효율적인 테스트 전략을 수립하여 실행 할 수 있을지에 대해 설명해줍니다.

테스트를 작성해야 하는 이유와 실무에서 테스트를 왜 쉽게 적용할 수 없는지에 대한 사례부터 시작해
테스트 작성 방법과 테스트를 작성하다 보면 할 수 밖에 없는 고민들에 대한 여러 노하우를 알려주면서
자연스럽게 공감대를 형성하게 되어 단순 테스팅 가이드이지만 마치 소설을 읽듯이 읽을 수 있게 되어 흥미로웠습니다.

무엇보다 흥미로웠던 부분은 목차에 팀원들을 설득하는 방법 이라는 소주제가 포함되어 있었는데, 마치 우리 팀의 상황을 보는 것 같아서 재밌었습니다.

지금까지 아무도 테스트를 작성하지 않았기 때문에 테스트 코드를 작성하지 않는 팀도 많다.
릴리즈된 후에는 방침을 바꾸는 것이 매우 어렵다. 그렇기 때문에 아무도 작성한 적이 없어 작성하지 않는다는 암묵적인 규칙이 생긴 것이다.

이 구문이 현재 우리팀의 상황과 100% 일치해 재밌었던 반면 약간 (?) 서글퍼졌습니다.

팀 전원이 테스트를 작성하도록 설득하려면 참고할 수 있는 테스트 코드가 있어야 한다. 아직 마땅한 자료를 찾지 못했다면 이 책을 참고할 수 있는 교재로 사용해보자.

하지만 이 구문을 보고 희망을 갖게 되었습니다.

저자 또한 이러한 환경에서 문제를 인식하고 직접 해결해봄으로써 저와 같은 개발자에게 도움이 되기위해 출판했구나 라는 생각이 들어서 어느정도 공감대가 형성된 것 같았습니다.

저 또한 마찬가지로 이 책을 참고 교재로 같이 활용해보면서 사내 테스트 가이드를 제작하기 위해 읽게 되었는데, 전체적으로 많은 도움이 되었습니다 :)

좋았던 점

책을 읽으면서 좋았던 부분은 아래와 같습니다.

현업에서 저자가 많은 고생을 하면서 얻게된 해결법들을 공유하기 위해 이 책을 썼다는 것을 느낄 수 있었습니다.

누구나 실패하지 않는 최선의 선택을 내리고 싶어한다. 하지만 프로젝트에서의 최선의 선택은 시간이 흐르면서 달라진다. 다행히도 프론트엔드 생태계에는 수많은 상황에 대응할 수 있는 다양한 테스트 방법이 있다 ... (생략)
-요시이 다케후미 (저자)

프론트엔드 테스트를 검색해보면 단위테스트, 통합테스트, E2E 테스트에 대한 글들이 대부분을 차지하고 있으며 다른 테스트 범위에 대한 설명이나, 다양한 프레임워크에 대한 글들은 찾기 힘듭니다.

아무래도 더 깊게 찾아보지 않는 이상 이 책에서 담고있는 UI 컴포넌트 테스트와 시각적 회귀 테스트 등에 대한 노하우는 본인이 직접 개발 환경이 잘 갖춰져 있는 회사에 입사하지 않는 한 경험해보기 힘들거라 생각했습니다.

레퍼런스를 찾기 힘든 것들에 대해 정말 실무 환경에 바로 적용해도 괜찮을 내용들이 포함되어 있어 좋았습니다.

어떠한 상황에서 어떤 테스트가 필요한지, 그리고 테스트를 어떻게 더 효율적으로 실행 할 수 있을지에 대한 내용들이 포함되어 있습니다.

테스트는 작성하는데 큰 비용이 들지 않고 운영 환경에 영향을 주지 않습니다.
이러한 특성 덕분에 어떠한 상황에서는 빠르게 작성되고 빠르게 폐기될 수 있다는 단점도 존재하기 마련입니다.

이런 상황에서 어떻게 해야지 더 좋은 방향으로 명시적이고 오래 사용 할 수 있는 테스트코드를 설계할 수 있는지에 대한 노하우가 담겨있습니다.

A+B = C 라는 기능을 테스트하는 방법은 수없이 다양합니다.
같은 테스트를 하더라도, 복잡한 테스트를 쉽게 풀어나갈 수 있는 방법들을 가르쳐주고 있습니다.

여러 케이스의 E2E 테스트에 대한 설명을 정확하게 포함하고 있습니다.

저는 E2E 테스트가 빨리 정의하고 작성하기 쉬워보이지만 가장 까다로운 테스트라고 생각합니다.
실제 DB 의 인앤아웃까지 고려하여 테스트가 진행되어야 하고, 테스트로 인한 변경점이 존재하게되면 범위가 겹치는 다른 케이스가 실패할 수도 있습니다.

이러한 환경까지 고려한 E2E 테스트 예제와 아티클은 존재하지 않았습니다. 존재하더라도 보통 사내에서 해결해나간 방법은 대외비가 되기 때문에 내용에는 굉장히 짧게 포함되어 있습니다.

이 책에는 E2E 케이스가 많아지더라도 어떻게 핸들링 해야 최대한 사이드 이펙트가 발생하지 않는 테스트를 실행할 수 있을지에 대해서 방법을 제시해줍니다.

테스트에 대한 설명과 함께 예제에 포함된 개념까지 깔끔하게 설명해줍니다.

테스트 케이스 작성에 웹 표준과 웹 접근성은 빠질 수 없는 개념이기도 합니다.
웹 표준과 접근성이 잘 지켜지지 않은 컴포넌트를 개발해오다가 테스트 코드를 작성하게 될 일이 흔하게 일어날거라고 생각이 들긴 하는데요,
이러한 상황에서 건강한 테스트 코드를 위해 컴포넌트를 어떻게 리팩토링 할 수 있을지에 대한 방향성을 제시해줍니다.

왜 웹 표준과 접근성을 준수하여 개발을 진행하는게 중요한지 직접 그 상황을 겪어보지 않으면 개념을 익히는데에도 어려움이 존재합니다.
이 책을 읽으면서 이런식으로 함께 알게된 개념들이 많아 살짝 부족했던 개념들까지 챙겨갈 수 있어 굉장히 유익했습니다.

아쉬웠던 점

솔직히 아쉬웠던 점을 정리하려고 생각해보니 딱히 떠오르지 않습니다.

지금까지 이 책보다 훨씬 불친절한 개발 서적들을 많이 봐왔습니다.
그리고 세상이 많이 발전한 탓에 바이블이라 칭해지는 책들에 포함된 내용을 인터넷에서 쉽게 찾을 수 있기도 합니다.

하지만 테스트에 대한 레퍼런스는 프론트엔드가 유명해지고 몇년이 지난 지금까지 찾기 힘듭니다.
이런 상황에서 오랜만에 얻어갈 것이 많은 책을 알게되어 기쁩니다.

누구에게 추천할까?

저처럼 당장 실무에서 가장 필요하고 해결되어야 하는 문제가 무엇일까에 대한 답변으로 테스트 자동화가 떠오르지만, 어디서부터 어떻게 풀어나가야 될지 모르겠는 주니어 개발자 분들께 추천합니다.

저는 큰 문제를 발견하면 일단 무작정 해결을 해본 뒤에 더 좋은 방법을 찾기 위해 다시 단위별로 분리하여 구체화 하고 차근차근 개선해나가는 방식으로 개발을 하곤 합니다.

지금 상황도 일단 특정 범위의 테스트를 통과시키고 이것을 운영 환경에 어떻게 붙일 수 있을지, 효율적으로 리소스를 낭비하지 않고 케이스를 작성하고 다룰 수 있을지에 대해 고민하는 상황이었구요.

저는 회사에 테스트 자동화에 대한 조언을 해줄 사수도 굉장히 많은 상황이기도 합니다.
이러한 환경에서도 사실 신선한 접근이 필요하다 생각했습니다.
정석이라 칭해지는 방법보다 더 나은 방법들이 존재할 수도 있기 때문입니다.

이런 고민 해결을 도와줄 수 있는 책이라 생각합니다.

테스트는 끝이 없습니다.
마치 어제 작성한 코드가 지금 보니 레거시인 것 처럼 테스트 코드 또한 어제 작성했던 코드보다 더 나은 설계 구조가 생각나기도 하고 수단이 떠오르기도 합니다.

이처럼 테스트에는 최고의 방법이나 패턴이 없고, 운영환경에 피해를 주지 않기 때문에
앞으로 꾸준히 테스트에 대한 고민이 생길때마다 반복적으로 읽어보려고 합니다 :)

profile
자스코드훔쳐보는변태

0개의 댓글