서론

운영중인 서비스에 새로운 feature나 급한 hotfix가 발생하여 개발을 하게 되면, 배포하기 전에 정상적으로 동작하는지 테스트를 해야한다.

만약에 테스트 코드가 없다면 어떨까? 내가 개발한 부분이 A를 클릭하고 거기서 B를 클릭한 후에 C를 클릭하고... 와 같이 복잡한 상황인 경우에 문제는 심각해진다. 개발하면서 계속 위의 케이스를 수동으로 동작시켜야 한다. 심지어 지금 개발한 부분 때문에 다른 기능들에게 까지 부수 효과(side effect)가 일어나지 않을 것이라고 장담할 수 없다. 꺼진 불도 다시 본다는 말이 있듯이 프로젝트의 주요 기능들을 모두 동작시켜보고 배포하는 것이 안전하다. 그런데 배포할 때마다 수동으로 기능들을 다 눌러본다고 하면, 벌써 아찔하다.

모두 E2E 돌려버리기?!

이제 테스트 코드가 필요하다는 것을 인지했을 것이다. 간단한 지식은 작년에 테스트를 처음 공부하는 프론트엔드 개발자의 개념 다지기를 작성하면서 알아보았다. 그리고 Jest나 testing-library를 사용하면서 간단한 ToDo 프로젝트에 실제로 적용해보기도 했다.

이 글을 작성하게 된 계기는 여기서 나온다. 현재 내가 속한 프론트엔드 팀에서는 테스트 코드를 작성하지 않는다. 하지만 위에서 언급했던 문제들을 과거부터 인식하고 있었고, 이제 부터라도 테스트 코드를 추가하려고 하고 있다. 그리고 함께 소통하는 과정에서 애플리케이션의 흐름을 처음부터 끝까지 테스트하는 것을 의미 하는 E2E에 대해서 이야기가 나왔다.

주제는 모든 테스트를 모두 E2E로 하면 어떨까? 였다. 유저 입장에서 정상적으로 사용한다는 것은 버그가 없다는 의미이다. 즉, 프로덕션에 배포해도 문제 없다는 것이다. 그렇다면 위에서 언급했던 문제점이 모두 사라지는 것이 아닐까? 그렇다면 모든 케이스를 E2E로 작성하고 단위 테스트는 필요 없을까?

물론 나는 이 방법이 옳지 않다는 것을 알고 있었다. 하지만 테스트 코드도 작은 프로젝트에서 사용해 본 경험이 전부이고, cypress같은 E2E 테스트 도구는 사용해보지도 않았다. 테스트에 대해 깊게 알고 있는 것이 아니기 때문에 그건 옳지 않다라는 의견을 내세우는데 신뢰를 주지 못했다.

우선, 나도 자세하게 아는 것은 아니라며 밑밥부터 깔고..
E2E는 느리다, E2E는 여러 상황들이 얽혀 있으므로 특정 기능 하나를 테스트하기에는 불리하다, E2E 테스트 코드 작성은 오래걸리는데 모든 테스트 시나리오에 할 수 있을까 등등 구구절절이었다. (물론 E2E만의 역할도 있다고 했다..!)

그러면서 Jest는 기능단위다, 나중에 코드를 설명하지 않아도 테스트 코드 작성된 것을 보면 이해하기 쉽다 등 단위 테스트에 대한 역할도 생각나는대로 말했다. 하지만 이미 얼버부리며 설명하는 나를 보았다. 오늘은 간단하게 E2E와 단위 테스트를 어느 상황에 맞게 사용하면 좋은지 알아보는 글이지만, 사실은 개발자로서의 반성문이 된 것 같다. 여태 서론이었고 이제 주제에 맞게 설명해보겠다.

그럼 어떤 경우에 뭘 써!!!

E2E

오늘 글의 핵심이다. 단위 테스트와 E2E 테스트는 목적에 따라 사용법이 다르다. E2E 테스트는 사용자의 관점에서 애플리케이션이 제대로 동작하는지 확인하는 목적으로 작성하기 때문에, 위의 대화에서 나온 문제점은 어느 정도 해결한다고 볼 수 있다.

블로그를 예로 들어보자. 아이디 암호를 입력해서 로그인 -> 새 글 작성 버튼을 클릭 -> 글 작성 -> 출간하기 버튼 클릭 과 같은 플로우를 코드로 작성할 수 있다. cypress를 사용하면 브라우저 종류도 선택할 수 있기 때문에 정말 유저 입장에서 테스트가 가능하다. 이 예시가 통과된다면, 벌써 로그인과 새 글 작성(api 통신 중 create) 등이 정상적으로 동작한다는 것을 알 수 있다. 중요한 부분들에 테스트 시나리오를 작성하고 E2E 테스트를 작성한다면 효율이 증가할 것이다. 즉, 장점을 살펴보면 이렇다.

• 시스템의 전체적인 품질 보증
• 실제 사용자의 환경에서 시스템이 작동하는 것을 확인
• 테스트 결과를 통해 사용자의 요구사항과 기대치를 충족

그리고 개발자가 새 기능을 추가하거나 버그를 해결하는 브랜치를 머지했을때, "나의 코드 때문에 다른 곳에 영향이 미치면 어떡하지?" 라는 걱정을 덜어줄 수 있다. 코드에 자신감이 생기고 개발하는 것에 두려움이 사라지는 것이다. 이는 개발 생산성에 중요한 영향을 미칠 것이다.

하지만 이렇게 완벽할 것 같은 E2E에도 단점이 있다.

• 테스트를 실행하는데 필요한 시간과 비용
• 오류가 발생한 경우, 어떤 부분에서 발생했는지 파악하기 어려움
  ( 여러 상황들이 얽혀 있어서.. )
• 시스템의 전체적인 흐름을 테스트하기 때문에 자동화하기 어려움
  • 다양하고 복잡한 환경을 구성하고 관리하기 어렵고, 종속성도 있음

물론 위의 단점이 있음에도 우리는 E2E 테스트를 작성해야 하는 것은 맞다. 왜냐하면 쉬운 작업이 아니더라도 장점이 명확하기 때문이다. 우리가 집중해야 할 부분은 테스트의 목적을 생각하고 E2E로 작성해야 할 부분과 단위 테스트를 할 부분을 분명히 하는 것이다.

단위 및 기능

Jest같은 단위 테스트에서는 각각의 기능에 대해 작은 범위에서 테스트 할 수 있다. 물론 모든 함수에 테스트를 추가할 수도 있지만, 중요한 로직이나 변경되지 않을 코어 로직들에 추가하는 것이 좋다. 우리는 시간이 없기 때문이다. 위에서 언급한 E2E에서 오류가 발생한 경우 지점을 찾기 어려운 문제점은 Jest를 병행함으로써 해결할 수도 있을 것이다.

단위 테스트는 개별 코드 블록이나 함수를 테스트하고, 기능 테스트는 특정 기능이 예상한대로 작동하는지 확인한다. 스토리북과 함께 사용하는 경우 스냅샷 테스트에도 용이하다. 장점은 아래와 같다.

• 빠르다
• 다양한 도구와 연동할 수 있다.
  • CI/CD 파이프라인에 쉽게 통합 가능
    ( 개발 및 배포 프로세스에서 테스트 자동화 )

하지만 당연히 단점도 있다. Jest에서 할 수 있는 것은 한계가 있기 때문에, 그 부분은 다시 E2E가 채워줄 수 있는 것이다.

물론 이 외에도 UI 테스트나 인테그레이션 테스트도 있다. 이들도 상황과 목적에 맞게 사용하는 것이다. 이 많은 테스트들을 모두 작성하면 좋겠지만, 계속 기능 개발을 하는 상황과 마감이 있는 현실에서는 쉽지 않다. 그러니까 더 더욱 가장 필요한 테스트를 가성비 좋게 추가하는 것이 중요할 것이다.

마무리

나는 어느정도 알고 있다고 생각한 것을 남에게 전달한다는 것이 얼마나 잘못된 일인지 깨달았다. 어느정도 안다는 것은 정확하게는 모른다는 의미이며, 이러한 지식은 남들에게 키워드정도는 던져줄 수는 있어도 지식 전달이나 설득하는 목적으로는 사용하면 안된다. 그래도 이번에 다시 정리해보는 시간을 갖고, 다시 팀원들에게 E2E와 단위에 대해서 공유를 했다. 결론적으로는 단위 테스트도 중요하다는 것을 어필할 수 있었다!