데보션앱 소개페이지 바로가기
로그인 선택

신고하기

CLOSE
신고사유 (대표 사유 1개)
상세내용 (선택)
0/200
  • 신고한 게시글은 더 이상 보이지 않습니다.
  • 이용약관과 운영정책에 따라 신고사유에 해당하는지 검토 후 조치됩니다.
  • 허위 신고인 경우, 신고자의 서비스 이용이 제한될 수 있으니 유의하시어 신중하게 신고해 주세요.
(이 회원이 작성한 모든 댓글과 커뮤니티 게시물이 보이지 않고, 알림도 오지 않습니다.)

미리보기

커뮤니티

      1,234

      badge 23.06.15

      글 등록

      카테고리를 선택해주세요.

      DEVOTEE를 활성화 시키면
      지금 작성한 커뮤니티 글에 대해 1개의 댓글을 달아줍니다.

      버튼을 누르면 글 수정 시 ChatGPT가 작성한 댓글이 수정됩니다.

      임시저장함에 저장되었습니다. 저장일시 : 2022.5.17 14:29:08

      임시저장함

      제목을 선택하시면 이어서 작성이 가능하며,
      최대 20건까지 저장합니다.
      컨텐츠 유형, 제목, 저장일시, 삭제로 이뤄진 임시저장 목록
      컨텐츠 유형 제목 저장일 삭제

      데보션 블로그 게재 요청

      CLOSE
      • *
      • *

      본인인증

      효율적인 데보션 서비스 이용 및
      고객님의 소중한 개인정보보호를 위해
      본인인증을 진행해주세요. 본인인증 미 진행 시 로그인이 제한됩니다.
      본인인증 실패

      본인인증 로그인에 실패하였습니다.
      회원이 아니시거나 본인인증 등록이
      완료되지 않은 사용자입니다.

      회원정보 연결

      에이닷 웹서비스팀의 E2E 테스트 도입기

      rangs919 25.09.03
      5,798 7 1
      DEVOTEE 요약
      에이닷 웹서비스팀은 QA 자동화를 위해 E2E 테스트를 도입하고, Playwright 및 Cursor를 활용해 테스트 코드 작성 및 품질 검증을 효율화했습니다. Playwright의 강력한 크로스 브라우저 지원과 디버깅 기능을 통해 테스트 생산성을 높였고, Cursor로 테스트 코드를 자동 생성하며 작업 속도를 획기적으로 단축했습니다. 이는 서비스 안정성과 사용자 경험 향상을 목표로 지속적인 테스트 자동화를 추진하는 데 기여했습니다.
      DEVOTEE 추천 블로그

      에이닷 웹서비스팀의 E2E 테스트 도입기

      에이닷은 SK텔레콤이 2022년 5월에 공개한 AI 에이전트 서비스입니다.

      에이닷 웹서비스개발팀은 adot.ai 웹사이트의 검색·노트 기능을 제공하고, 앱 내 웹뷰 개발까지 담당하며 다양한 웹 기술로 사용자 경험을 강화하고 있습니다.

      2025년, 저희 팀의 목표 중 하나는 테스트 코드 작성 및 운영 체계화였습니다.

      특히 QA 자동화를 위해 E2E(End-to-End) 테스트를 본격적으로 도입해본 경험을 공유해보려 합니다.


      테스트 코드 세 가지 범주

      테스트 코드는 크게 세 가지로 나눌 수 있습니다.

      • Unit Test

      • Integration Test

      • E2E Test

        이 세 가지는 실행 환경, 시점, 복잡성 등에서 차이가 있으며, E2E 테스트는 특히 실제 사용자의 서비스 흐름 전체를 자동화해 검증한다는 점에서 가장 큰 차이점을 지니고 있습니다.


      Unit Test

      Integration Test

      e2e Test

      환경

      개발 단계

      실제 데이터베이스나 외부 서비스와의 연동을 포함할 수 있음

      프로덕션과 유사한 환경에서 실행

      실행 시점

      개발 단계에서 실행

      단위 테스트 이후, E2E 테스트 이전에 실행

      개발 후반부나 릴리즈 직전에 실행

      복잡성

      가장 단순하고 빠르게 실행됨

      단위 테스트보다 복잡하며, 실행 시간도 더 길다

      가장 복잡하고 실행 시간이 길다

      범위

      개별 함수, 메서드, 클래스 등 가장 작은 단위의 코드를 테스트

      여러 모듈이나 서비스 간의 상호작용

      전체 애플리케이션의 흐름을 사용자 관점에서 테스트

      목적

      개별 컴포넌트의 정확성을 검증

      컴포넌트 간의 인터페이스와 데이터 흐름을 검증

      실제 사용자 시나리오를 시뮬레이션하여 전체 시스템의 동작을 검증


      E2E 테스트의 장점과 단점

      장점

      • 전체 플로우 검증

        “로그인 → 페이지 이동 → 버튼 클릭 → 결과 확인”처럼 실제 사용자 시나리오 전체를 확인 가능합니다

      • 실제 브라우저 환경 실행

        Playwright, Cypress, Selenium으로 DOM 클릭·입력 등 실제 사용과 유사하게 동작을 검증할 수 있습니다

      • 품질 보증

        프론트엔드·백엔드 연결 상태와 주요 기능의 안정성 테스트 할 수 있습니다

      단점

      • 실행 속도가 느리고, 작성·유지보수 비용이 높습니다

      • 도입 시 초기 설정과 러닝커브 필요합니다


      도구 비교: Cypress vs Playwright vs Selenium

      테스트 도구 선정 전, 대표적인 세 가지 도구를 비교했습니다.

      결론: 크로스 브라우저 지원, 병렬 처리, CI/CD 연동 측면에서 저희 팀은 Playwright를 선택했습니다.

      구분

      Cypress

      Playwright

      Selenium

      브라우저 지원

      Chrome, Firefox, Edge

      Chrome, Firefox, Safari, Edge

      Chrome, Firefox, Safari, Edge, Opera

      언어 지원

      JavaScript, TypeScript

      JavaScript, TypeScript, Python, Java, C#

      Java, Python, C#, Ruby, JavaScript 등

      테스팅 기능

      • 사용자 친화적인 인터페이스로 프론트엔드 테스팅에 탁월

      • 테스트 중 실시간 업데이트 제공하는 GUI 제공

      • 내장된 성능 테스팅 기능 부족

      • cypress studio로 코드 자동 생성 가능하나 아직 실험적 기능

      • API, UI 및 시각적 테스팅이 결합된 복잡한 웹 앱에 적합

      • 대규모 테스트 스위트에 대한 우수한 병렬 처리 및 확장성

      • 페이지 로드 시간 측정 성능 테스팅 기능 제공

      • 네트워크 요청 인터셉션

      • 파일 다운로드/업로드 지원

      • 지리적 위치 모킹

      • 권한 및 인증 테스트

      • codegen으로 코드 자동생성

      • 웹 요소 조작 및 검증

      • 프레임/윈도우 전환 지원

      • 키보드/마우스 이벤트 시뮬레이션

      • 명시적/암시적 대기 기능

      디버깅 및 문제 해결

      실시간 테스트 실행, 비디오 녹화, 타임 트래블 디버깅 같은 기능 제공

      Playwright도 강력한 디버깅 기능 제공. Cypress 수준의 상호작용성을 달성하려면 추가 설정 필요

      • 스크린샷 캡처

      • 로그 기록

      • 브라우저 개발자 도구 통합

      초기 설정

      빠른 설정과 실행

      빠른 설정과 실행

      상대적으로 복잡

      장점

      • 실시간 테스트 실행

      • 사용자 친화적 대시보드

      • 시간 여행 디버깅 기능

      • 자동 대기(Auto-waiting) 기능

      • 네트워크 트래픽 모킹/스터빙 기능

      • 우수한 디버깅 (스냅샷/비디오 녹화)

      • 크로미움(Chrome/Edge), Firefox, WebKit(Safari) 지원

      • 복잡한 시나리오 대응 우수

      • 병렬 실행/헤드리스 모드

      • 빠른 실행 속도

      • 모바일 에뮬레이션

      • 다중 언어 지원

      • 자동화 대기 기능

      • 다양한 언어 지원

      • 다양한 플러그인

      • 광범위한 브라우저 지원

      • 대규모 커뮤니티

      • 폭넓은 사용 사례

      단점

      • 주로 Chromium 기반 브라우저/Firefox 지원 → Safari/WebKit 부족

      • 단일 탭/도메인 제한

      • 복잡한 시나리오 테스트 제한

      • JS/TS만 지원

      • 학습 곡선 높음

      • 초기 설정 복잡할 수 있음

      • 설정 복잡

      • 실행 속도 느림

      성능 비교

      평균 9.378초 (가장 느림, Playwright 대비 2배 이상)

      평균 4.513초 (가장 빠른 실행 속도)

      평균 4.590초 (두 번째로 빠름)

      • 포괄적인 크로스 브라우저 테스팅을 지원하고, 복잡하고 대규모 프로젝트를 위한 고급 병렬 처리가 가능하며 CI/CD 연동 용이성을 고려하여 Playwright를 선택하였습니다.


      Playwright 도입기

      설치 및 실행

      설치와 실행 그리고 report를 보는 방법은 아래의 간단한 명령어로 가능합니다

      • 설치: npm init playwright@latest

      • 실행: npx playwright test

      • report 보기 : npx playwright show-report

      codegen으로 빠른 코드 생성

      • Playwright의 codegen 기능은 테스트 코드를 자동으로 초안화해주는 강력한 도구입니다

      • local서버를 구동시켜두고 이를 타겟으로 codegen 실행하는 방법은 아래와 같습니다

        npx playwright codegen https://localhost:3000 --ignore-https-errors

        Screenshot 2025-08-27 at 8.08.38 PM.png

      • Codegen을 통해 테스트 초안을 작성하는 과정에서 DOM selector 탐지할 수 있습니다

        Screenshot 2025-08-27 at 8.13.38 PM.png

      • input 입력하는 코드를 자동화할 수 있습니다

        Screenshot 2025-08-27 at 8.12.48 PM.png

      selector는 data-testid로 관리하는것이 합리적

      • Codegen이 작성해준 E2E테스트 초안은 처음엔 무척 간편하다는 느낌을 안겨주었습니다.

        하지만 서비스는 빠르게 변화하고 그에 따라 코드의 변경점이 늘어날 수록 Selector에 대한 고민이 늘어났는데요.

      • 결과적으로 class, id, DOM 구조는 언제든 변경될 수 있다는 점에서 점차 data-testid 기반 selector를 사용하는 방식으로 정착하게 되었습니다.

      Repo 관리 전략

      • 초기에는 개발 Repo와 테스트 Repo를 분리해서 관리하는 것으로 시작하였습니다.

      • 하지만 실제 경험상 하나의 Repo에서 개발 코드와 테스트 코드를 함께 관리하는 것이 훨씬 효율적이라는 결론을 얻었습니다.

        이유는 다음과 같습니다:

        • product 코드 변경시 → 테스트 코드도 즉시 반영 필요합니다.

        • data-testid 같은 속성은 product 코드에 직접 추가해야 하는 점에서도 역시 하나의 Repo에서 관리가 필요했습니다.

      Playwright UI 모드를 시작해보기

      • playwright는 UI모드로 테스트를 실행할 수 있습니다.

        npx playwright test --ui

      • UI모드에서는 테스트 전체 과정이 스크린녹화되어 기록되고 원하는 시점에 mouse hover하여 테스트 과정을 step by step으로 확인 가능합니다.

        Screenshot 2025-08-27 at 8.16.55 PM.png

      • 특정 테스트 watch mode 실행을 하면 코드를 수정하고 저장 시 테스트가 자동 재실행이 되어 유용합니다.

      • 스크린 녹화와 watch mode는 특정 테스트를 디버깅하고 빠른 피드백을 받기에 큰 도움이 되었습니다.

        Screenshot 2025-08-27 at 8.17.09 PM.png

      로그인 테스트와 Anti-bot 회피

      • 로그인 플로우를 테스트 코드로 구현했을 때, 단순히 fill만 사용하면 너무 빠른 입력에 의해 로봇 탐지에 걸려 로그인에 실패합니다.

      • 이를 해결하기 위해 랜덤 wait를 삽입하여 실제 사용자 입력과 유사하게 만들어 안정적으로 로그인을 시킬 수 있었습니다.


      Cursor를 활용한 코드 자동화

      • QA팀에서 에이닷 노트라는 서비스를 타겟으로 작성하고 공유해주신 테스트 코드는 무려 248개나 되는 방대한 분량이었습니다.

      • 모든 코드를 수작업으로 작성하기엔 비효율적이었고, Cursor를 활용하기 시작하였습니다.

      • 방법은 간단했는데요 먼저 Cursor에 아래와 같이 QA팀에서 제공해주신 TC 를 스크린샷해서 첨부합니다.


        Screenshot 2025-08-25 at 6.16.23 PM.png


      • “이 스크린샷 기반으로 테스트 코드를 작성해줘. 티켓 넘버를 주석으로 달아줘.”라고 입력하면 자동으로 테스트 코드 생성됩니다'

        Screenshot 2025-08-27 at 9.02.40 PM.png

      • 여러 테스트를 추가하다보면 테스트가 실패하기도 하는데요 이때 “실패하는 테스트는 예외 처리 추가해줘.” 라고 입력하면 즉시 수정을 진행합니다

      • Cursor를 도입하면서 자동 코드 생성과 즉시 수정을 반복하며 코드 작성 속도를 획기적으로 단축할 수 있었습니다.


      E2E Test는 어떤 목표를 잡고 진행하는게 좋을까?

      • Unit Test의 경우 전체 Code coverage의 60% 이상 작성하기 같은 목표를 수립하곤 합니다. E2E 테스트는 어떨까요?

      • E2E테스트는 테스트의 목적과 사용자의 사용성을 테스트 하는 것이기에 Code Coverage를 목표로 설정하는 것의 의미가 크지 않습니다.

      • 팀에서 선정한 중요도 높은 TC들에 대해 테스트를 작성하는 것으로 목표를 수립하였고 QA팀이 제공해주신 TC의 50% 이상의 TC를 작성하는 것으로 목표를 수립하고 진행하고 있습니다.


      맺음말

      E2E 테스트는 빠른 실행·간단한 유지보수와는 거리가 멀지만, 서비스 전체 품질을 보장하는 핵심 역할을 합니다.

      에이닷 웹서비스팀은 Playwright와 Cursor를 도입해 방대한 QA 시나리오를 효율적으로 자동화하고, 이를 통해 개발자와 QA 모두의 생산성을 높일 수 있었습니다.

      앞으로도 저희는 사용자 경험을 깨뜨리지 않는 안정적인 서비스 제공을 위해 테스트 자동화를 꾸준히 발전시켜 나갈 계획입니다.

      댓글 0

      DEVOTEE를 활성화 시키면
      지금 작성한 댓글에 AI가 댓글을 달아줍니다.

      rangs919 님의 최신 블로그

      더보기

      DEVOTEE 추천 블로그

      동영상 기고하기