Skip to main content

Command Palette

Search for a command to run...

웹 프론트엔드 테스트에 대한 개인 생각

필수 테스트에 대한 생각 정리

Updated
2 min readView as Markdown
웹 프론트엔드 테스트에 대한 개인 생각
T

Software engineer for web tech. Interested in sustainable growth as software engineer.

사실 모든 테스트는 필수가 아닙니다. 테스트 없어도 소프트웨어가 작동은 하니까요. 하지만 테스트가 꼭 필요하다는 전제 하에 생각해봤습니다.

웹 프론트엔드 테스트를 적용할 수 있는 많은 테스트들이 있습니다. 그 중 보편성이라는 기준에 따라 총 다섯 가지 테스트로 분류하여 생각해봤습니다.

  1. E2E 테스트(End-to-End Test): 사용자 관점에서 제품의 처음부터 끝(백엔드)까지 모든 과정을 테스트 할 수 있습니다.

  2. 유닛 테스트(Unit Test): 소프트웨어를 구성하는 가장 작은 단위(함수 등)의 동작을 검증하는 테스트입니다.

  3. 통합 테스트(Integration Test): 개별 모듈을 결합하여 그룹으로 실행되는 테스트입니다.

  4. UI 테스트: 사용자 인터페이스가 정확하게 동작하는지 확인하는 테스트입니다.

  5. 성능 테스트(Performance Test): 소프트웨어의 응답 시간, 처리량, 자원 사용량 등을 측정하는 테스트입니다.

이 중 제가 생각했을 때 자동화하면 좋은 필수 테스트와 꼭 자동화 하지 않아도 되고 선택적으로 적용할 테스트가 무엇인지 생각을 정리해봤습니다.
테스트는 있으면 좋기 때문에 기본적으로 소거법으로 생각하여 필수와 옵션으로 분류해봤습니다.

필수 테스트 2개

  • 유닛 테스트: 가장 작은 단위의 코드가 의도대로 정확히 작동하는지 검증해주며, 빠른 피드백과 초기 문제 해결을 가능하게 해줍니다. 리팩토링이 필요할 때 매우 큰 힘이 됩니다. 소프트웨어의 성장으로 인해 변동이 클수록 빛을 발하는 필수 테스트입니다.

  • E2E 테스트: 사용자 관점에서 소프트웨어의 전체 흐름을 테스트함으로써, 실제 사용자 경험에 가까운 테스트를 제공해줍니다. 가벼운 수준으로 페이지들의 정상 작동 여부만 파악할 수도 있고, 소프트웨어에서 가장 망가지면 안될 기능들에 적용 시켜둘 수도 있는 필수 테스트입니다.

옵션 테스트 3개

  • 통합 테스트: 어디까지 통합하여 테스트할 지에 대한 경계 설정이 어렵고, 결국 목 데이터가 많이 적용 되기 때문에 테스트를 위한 테스트를 작성하는데 시간과 비용이 쏟아 부어질 위험이 큽니다. 시스템의 핵심적인 데이터 흐름이나 비즈니스 로직에 적용하기 좋지만, 이러한 통합 테스트를 추가하거나 수정해야 될 필요가 생기면 팀과의 소통을 통해 조심스럽게 진행해야 됩니다.

  • UI 테스트: UI의 변동성과 개발 초기 단계에서의 불확실성은 UI 테스트의 개발 및 유지 보수 비용을 크게 증가 시킬 수 있습니다. UI의 핵심 기능이나 자주 사용되는 컴포넌트, 사용자 경험이나 접근성에 대해 테스트가 꼭 필요하면 적용할 수 있습니다.

  • 성능 테스트: 성능에 민감한 기능의 초기 적용 시기에는 필수로 적용할 수 있겠지만, 일회성에 가까운 테스트기 때문에 자동화 테스트 적용 혹은 지속적인 유지 보수를 하기에는 비용 대비 효과가 떨어집니다. 특히 성능 테스트의 경우 테스트의 성격에 따라 시간이 오래 소요될 수 있기 때문에 자동화하면 전체 시스템이나 업무에 병목지점이 될 수 있습니다.

마치며

정말 간단하게 정리하게 해봤습니다. 소프트웨어가 수명을 갖는다는 개념을 갖게 된 후 테스트의 중요성에 대해 점점 체감하고 있습니다. 테스트에 대해 고민하실 때 참고가 되었으면 좋겠습니다.
다음에는 각 테스트에 적용하기 좋은 기술들, 예제 코드, 작성시 주의사항 등을 정리해보도록 하겠습니다.

More from this blog

프론트엔드는 경계를 다루는 직무가 되어간다

프론트엔드는 원래도 복잡했습니다. 브라우저마다 다른 렌더링, 상태 동기화, 성능, 접근성 — 화면 하나 제대로 만드는 데 신경 쓸 게 늘 많았습니다. 다만 그 복잡함은 대체로 한 방향을 향했습니다. 이 UI를 어떻게 만들까, 상태를 어떻게 관리할까, 클릭하면 무엇이 바뀌어야 할까. 그런데 요즘 질문의 축이 하나 더 늘고 있습니다. 이 UI는 서버에서 먼저

Jul 20, 20266 min read

AI가 코드를 짜는 시대, 나는 리뷰를 못 따라가고 있었다

솔직히 말하면, 요즘 PR을 제때 리뷰하지 못하고 있습니다. 개발 속도는 빨라졌는데 리뷰 속도는 그대로입니다. 예전엔 하루 이틀이면 처리하던 게 이제는 며칠씩 밀립니다. 처음엔 제가 게을러진 탓인가 싶었습니다. 돌아보니 그게 아니었습니다. AI 도구를 쓰면서 코드가 쏟아지는 속도가 달라졌습니다. 한 사람이 만들어내는 코드 양이 예전과 비교가 안 됩니다. P

Mar 18, 20263 min read
AI가 코드를 짜는 시대, 나는 리뷰를 못 따라가고 있었다

테드풀의 한 입 지식

78 posts

가볍게 정리하는 기록들입니다.