안녕하세요, 이번 글에서는 FrontEnd 개발 과정에서 테스트를 더하여 개발을 좀 더 효율적이고, 실수를 줄일 수 있는 방법에 대해 이야기 해 보겠습니다.들어가며저는 최근 까지도 FrontEnd 개발을 하며 테스트의 필요성을 크게 느끼지 못하였고 동료들 간에도 많은 의견이 나오는 주제 중 하나 인데요, 당연히 테스트 코드가 필요한 것처럼 보였지만 막상 개발을 진행하다 보면 HMR (Hot Module Replacement)을 활용하고 있기에 굳이 필요하지 않은 것처럼 보이기도 합니다. 브라우저를 띄우고 코드를 수정하면 알아서 변경된 부분을 반영해 주고 내가 직접 클릭하면서 동작을 검증하는 과정을 하면 귀찮은 테스트 코드는 작성하지 않아도 될 것 같습니다. 저도 처음에는 이러한 생각에 동의했습니다. 프로젝트의 기한이 얼마 남지 않았고 빠르게 개발이 되어야 할 때 테스트 코드를 작성하는 시간에 개발 코드를 좀 더 작성하여 개발 기한 준수에 중점을 두는 게 더 나은 선택인 것으로 생각했습니다. 하지만 요즘은 조금씩 생각이 달라지고 있습니다. 점점 테스트 코드에 대한 필요성이 보이기 시작하더니 테스트 코드를 적용한다면 오히려 효율적이고, 더 나은 품질의 코드를 작성할 수 있겠다는 생각이 들었습니다. 그래서 이번 글을 통해 제가 왜 이러한 생각을 가지게 되었고, 어떠한 방법을 생각 중인지 이야기해보겠습니다.테스트가 필요 없다고 생각했던 이유제가 테스트가 필요가 없다고 생각했던 이유는 HMR(Hot Module Replacement) 덕분이었습니다. HMR은 개발 시 코드의 수정이 발생하면 새로고침이 필요 없이 런타임에서 업데이트 할 수 있습니다. 단순히 브라우저에 개발 중인 화면을 띄우고 코드를 수정하고 저장만 누르면 수정된 부분을 바로 볼 수 있고, 내가 직접 화면을 눌러 테스트를 해볼 수 있기 때문입니다. 그렇다면 이렇게 편한 HMR에 대해 조금 더 알아보겠습니다.HMR에 대하여개발을 진행하며 코드를 수정하면 Webpack Dev Server는 변경 사항을 감지합니다. 변경 사항이 발생하면 이를 WebSocket을 통해 브라우저에 업데이트를 전송하고 브라우저는 이를 전송 받으면 해당 모듈을 교체하고 변경된 내용을 반영합니다.hmr을 사용할 때의 프로세스 간소화이러한 간단한 원리로 개발의 편의성을 향상 시켜주고 있습니다. Webpack의 config파일에서 설정이 가능한데, Webpack Dev Server v4부터는 HMR이 기본으로 활성화 되어 있다고 합니다.webpack hmr 설정최근에는 Vite를 활용하여 개발을 많이 진행하고 있습니다. 저 역시 Vite를 활용하고 있습니다. Vite 또한 Webpack Dev Server와 동일한 원리로 파일 변경을 감지합니다. 가장 큰 차이점은 네이티브 ES 모듈을 활용한 점입니다.테스트가 필요하다고 느껴진 이유하지만 그 와중 테스트가 필요하다고 생각 들었던 가장 큰 이유는 다양한 테스트 케이스를 대응하는 것이 필요해졌기 때문입니다. 개발 중인 코드에서 테스트를 하는 것에는 한계가 존재하였습니다. 특정 한 상황을 가정하기 위한 데이터가 필요한 상황도 있었고 개발 중인 페이지만 동작을 확인하는 경우에는 다른 페이지에 미칠 수 있는 영향을 놓치는 경우도 발생하였습니다. 특정한 상황을 가정하기 위하여 MSW(Mock Service Worker)를 사용해보기도 하였으나 전체적인 부분을 모두 테스트 해보기에는 한계가 보였습니다. 개발이 잘 되었다 생각하면 QA 과정에서 생각지 못한 상황의 이슈가 올라오고, 이러한 과정들이 쌓이면서 우리가 개발 과정에서 테스트를 한다면 더 자신있게 개발이 완료되었다 라고 말 할 수 있을 거라 생각했습니다. 그렇기에 저는 아래처럼 개발 과정을 바꾸어 보려 했습니다.테스트 방법들테스트 방법들은 크게 단위 테스트(Unit Test), 통합 테스트(Integration Test), E2E 테스트로 나눌 수 있습니다. 각 테스트의 특징은 아래와 같습니다.단위 테스트정의: 특정 함수, 컴포넌트, 모듈 등의 작은 단위의 코드를 위주로 올바르게 작동 하는지 검증합니다.목표: 각 단위 기능을 독립적으로 확인하여 검증합니다.특징: 단위가 작으므로 빠른 실행이 가능하고, 코드 작성과 동시에 바로 테스트를 진행하기에 문제 발견이 빠르게 이루어질 수 있습니다.도구: Jest, Vitest, React Testing Library 등을 이용하여 단위 테스트를 진행합니다.통합 테스트정의: 복수 개의 단위 또는 모듈이 함께 작동하는지 검증합니다.목표: 각 단위의 상호 작용이 올바르게 이루어 지는지, 데이터가 단위 간 예상한 대로 전달 되는 지 등을 확인합니다.특징: 여러 단위의 연관성을 확인하며 API 연동 테스트 등도 주로 통합 테스트 이상의 규모에 진행합니다. 또한 실제 환경과 유사한 환경에서 검증합니다.도구: Jest, Vitest, Cypress, Playwright 등을 활용하여 검증합니다.E2E 테스트정의: 실제 사용자의 입장과 동일한 환경에서 전체적인 흐름을 검증합니다.목표: 사용자가 실제 어플리케이션을 사용하는 과정에서 발생하는 모든 단계를 테스트 하여 실사용에 문제가 없는지 확인합니다.특징: 실제 사용자의 입장과 동일한 환경이므로 가장 정확한 결과를 얻을 수 있습니다. 하지만 그만 큼 규모가 큰 테스트로 자원 소모가 크다는 단점이 있습니다.도구: Cypress, Selenium, Playwright 등으로 검증합니다.내가 선택한 테스트 방법이러한 특징들을 고려하였을 때 지금 상황에서 가장 필요한 것은 통합 테스트 였습니다. 어플리케이션을 개발하는 과정에서 그 페이지가 기획서 대로 flow가 동작하는지, 이때 모듈간 또는 페이지 간의 흐름이 정상적으로 동작하는지 검증이 가장 필요했습니다. 통합 테스트 도구 중에는 playwright와 cypress 둘 중에 고민하였습니다. jest와 vitest도 통합 테스트에 활용될 수 있지만 여러 브라우저들을 대상으로 테스트를 할 필요가 있기에 고려 대상에서 제외 하였습니다.playwright와 cypress를 비교한다면 간단히 아래처럼 표로 나타낼 수 있습니다.기능Playwrigh

안녕하세요. LINE NEXT DevOps 팀에서 쿠버네티스 운영 및 유지 보수, CI/CD 구축, 모니터링, 로그 수집 등 인프라 전반에 걸쳐 업무를 수행하고 있는 이동원입니다. 이번 글에서는 새로운 도구를 활용해 장애/변경 알림 및 관리 시스템을 구축한 과정을 소개하겠습니다.이 글은 먼저 발행했던 ChatOps를 통한 업무 자동화(feat. Slack Hubot) 글과 이어지는 글로, 이번에 새로 소개할 도구는 Playwright라는 E2E(End-to-End) 모니터링 도구입니다. Playwright를 이용해 모니터링 관제를 수행하고, Jira를 이용해 장애 및 변경 티켓을 관리하며, 봇을 이용해 Slack으로 알림을 보내고 Jira를 제어하는 시스템을 구축했습니다. 그 과정을 상세히 소개하겠습니다.LY에서는 타 회사의 TTS(Trouble Ticket System)라는 시스템을 이용해 변경 관리 및 장애 관제를 수행하고 있었습니다. 그러나 타 시스템에 의존적이었고, 시스템을 별도로 운영하다 보니 모니터링과 변경, 장애에 대한 시스템 제어권이 없었습니다.이런 상황에서 장애 발생 후 이를 처리하는 데 소요되는 시간을 분석해 보았는데요. TTS로부터 장애 알림을 받은 후, 장애 대응 및 조치까지 걸리는 시간은 다음과 같았습니다. 2023년 1월부터 2024년 현재까지 발생한 이력을 x축으로, 장애 소요 시간을 y축으로 나타낸 그래프입니다.대체로 장애 처리는 1시간 이내에 완료됐으나, 가장 오래 소요된 상위 5개 사례에서는 1시간을 초과한 것으로 나타났습니다. 결과를 분석해 보니 대체로 장애 급수가 낮을수록 장애 복구에 오래 걸리는 경향이 있다는 것을 알 수 있었는데요. 비즈니스에 끼치는 영향도가 낮은 장애라도 서비스의 이상 유무는 사용자에게 영향을 미칠 수 있기 때문에 모든 장애에 대해 신속하게 알림을 받고 처리하는 것이 필요했습니다.보통 장애 처리는 크게 '장애 지속 시간을 줄이는 작업'과 '사후 처리'로 나눌 수 있습니다. 먼저 장애 지속 시간을 줄이는 작업은 다음과 같은 과정으로 진행됩니다.• 이상 징후 탐지 : 시스템이나 서비스에서 정상적이지 않은 동작이나 성능 저하를 감지하는 과정• 의사 결정 : 탐지된 이상 징후에 대한 대응 방안을 결정하는 과정• 시스템 복구 : 장애를 해결하고 시스템이나 서비스를 정상 상태로 되돌리는 과정다음으로 사후 처리 과정은 다음과 같습니다.• 영향도 파악 : 장애가 시스템, 서비스, 사용자에게 미친 영향을 평가하는 과정• 상세 원인 분석 및 재발 방지 : 장애의 근본 원인을 철저히 분석하고 동일한 문제가 다시 발생하지 않도록 예방 조치를 취하는 과정저희는 그중에서 아래와 같이 장애 지속 시간을 줄이는 데 초점을 맞추고, 이를 위해 기존에 사용하던 TTS을 대체할 시스템 조사해 새로운 시스템을 구축하기로 결정했습니다.기존 시스템을 대체할 새로운 시스템을 구축하기 위해서는 먼저 기존 시스템을 이해하는 것이 필요했습니다. 이에 기존 시스템이 제공하는 기능과 프로세스를 파악한 후 새로운 시스템이 이를 충분

안녕하세요, 우아한형제들 디자인 시스템 ‘우아한공방’의 웹 프론트엔드 개발자 금교영, 이수정입니다. 우아한공방은 우아한형제들에서 운영하는 다양한 웹/앱 프로덕트에서 사용되고 있는데요. (참고: 우아한형제들의 새로운 디자인 시스템 ‘우아한공방’을 소개합니다: 개발 편) 이번 글에서는 우아한공방에 시각적 회귀 테스트를 도입한 과정에 대해 이야기해 보려고 합니다. ‎시각적 회귀 테스트(Visual Regression Test)는 코드 변경 전/후의 스크린샷을 비교해 차이를 감지하고 예기치 못한 오류를 확인하여 UI의 시각적 일관성을 제공할 수 있도록 하는 테스트입니다.그렇다면, 디자인 시스템에 시각적 회귀 테스트가 왜 필요할까요? 우아한공방은 총 115가지의 UI 컴포넌트를 제공하고 있어요. 우아한공방의 컴포넌트 단위 테스트의 커버리지를 91%로 유지하고 있지만, 단위 테스트로는 확인할 수 없는 UI 변경 사항이 있습니다.A 컴포넌트를 변경했는데 해당 컴포넌트를 의존하는 다른 컴포넌트가 예상 못한 방식으로 변경되면서 A 컴포넌트에 의존하는 모든 컴포넌트를 확인해야 하는 경우가 있었습니다.또한, 디자인 시스템 패키지의 스타일 코드 전체에 영향을 미치는 작업으로 인해 모든 컴포넌트에 UI 변경 사항이 발생했는지 확인해야 하기도 했습니다.변경 사항을 일일이 확인하는 데에는 상당한 시간이 필요하고, 미세한 변화는 알아차리기 어렵습니다. 예상치 못한 변경 사항이 적용된 컴포넌트가 사용자에게 보이면 앱의 품질을 저하시키는 요인이 될 수 있고 사용자에게 불편함을 줄 수도 있습니다.이러한 문제를 해결하여 컴포넌트의 시각적 안정성을 확보하고자 시각적 회귀 테스트를 도입했습니다.그럼, 이제 시각적 회귀 테스트를 어떻게 구현했고, 어떻게 안정성을 확보할 수 있었는지 같이 살펴보시죠!시각적 회귀 테스트를 지원하는 도구에는 Playwright, BackstopJS, Chromatic 등이 있습니다. 저희는 다음과 같은 이유로 Playwright를 선택했습니다.• 무료로 사용 가능합니다.• 추후 E2E 테스트(end-to-end test)로 확장하여 다양한 시나리오를 테스트할 수 있습니다.• HTML로 제공하는 테스트 리포트로 결과를 확인하고 디버깅할 수 있습니다.Chromatic의 경우 유료여서, BackstopJS는 한글을 지원하지 않아 제외했습니다.우아한공방에는 컴포넌트 개발을 위한 세 가지 환경이 있습니다.• 스토리북 : 디자이너도 쉽게 UI를 확인할 수 있어서 디자인 QA 용도로 사용합니다.• 테스트 앱 : SSR(server-side rendering) 환경과 다양한 번들러에서 컴포넌트가 잘 동작하는지 확인하기 위해서 운영하고 있습니다.• 공식 문서 사이트 : 디자이너와 개발자에게 사용 방법을 가이드하는 웹사이트입니다.위 세 가지 중, 저희는 스토리북을 테스트베드로 선택했습니다. 그 이유는 가장 빠르게 시각적 회귀 테스트를 도입할 수 있는 방법이라고 판단했기 때문입니다. 구체적인 선정 기준은 다음과 같아요.• 추가 코드 작성이 적을 것시각적 회귀 테스트에서 비교할 엘리먼트를 정확하게 선택하는 것이 중요한데요. ‘공식문서 사이트’는 이 과정이 까다로워서 제외했어요. ‘테스트 앱’은 엘리먼트 선택은 비교적 쉬웠으나 모든 컴포넌트에 대한 코드가 작성된 상황이 아니어서 추가로 작성해야 할 코드가 많아서 제외했습니다.반면, 스토리북을 사용하면 간단하게 테스트 코드를 구성할 수 있습니다. 컴포넌트가 렌더링되는 부분은 iframe으로 제공되기 때문에 iframe 경로에 접속하면 컴포넌트만 렌더링된 화면을 확인할 수 있습니다. 덕분에 스크린샷을 찍을 때 엘리먼트를 선택할 필요가 없습니다.또한 우아한공방에서는 프로젝트 초기부터 개발 및 디자인 QA 단계에서 스토리북을 적극적으로 활용해 왔습니다. 총 115개의 컴포넌트에 대해 상태별 스토리가 이미 잘 작성되어 있었습니다. 덕분에 다른 테스트베드 후보와 달리 시각적 회귀 테스트를 위해 추가적인 코드 작성할 필요가 없이 그대로 사용할 수 있었습니다.이제 시각적 회귀 테스트를 실행하는 방법을 알아봅시다. Playwright의 toHaveScreenShot() 메서드를 사용하면 간단하게 스크린샷을 찍고 비교할 수 있습니다.테스트를 실행하면 test-results 폴더에 시각적 비교에 필요한 3가지 이미지가 생성됩니다. 각 이미지의 파일명은 -expected, -actual, -diff 접미사를 가집니다.3가지 스크린샷은 다음과 같아요.• 기대한 이미지(expected) ‘기대한 이미지’는 이전에 저장된 스크린샷입니다.• 실제 이미지(actual) ‘실제 이미지’는 가장 최근에 생성된 스크린샷입니다.• 차이 이미지(diff) ‘차이 이미지’는 ‘기대한 이미지’와 ‘실제 이미지’ 간의 픽셀 차이를 강조한 이미지입니다. 픽셀 매치에 따라 어떤 부분이 변경되었는지 시각적으로 확인할 수 있습니다.만약 테스트 환경 구축 후 처음 테스트를 실행하거나, 컴포넌트가 새로 추가되어 비교할 스크린샷(expected)이 없다면 어떻게 될까요?비교할 ‘기대한 이미지(expected)’가 없으니, 해당 테스트는 실패합니다.앞서 toHaveScreenShot()은 3가지 이미지를 만들었었죠. 하지만 이전에 찍어둔 스크린샷이 없는 경우에는, 오직 현재의 스크린샷 이미지 하나만 생성합니다. 대신 이 때 생성한 이미지는 다음에 실행하는 테스트에서 ‘기대한 이미지(expected)’로서 동작하고, 그 때부터 기대한 대로 테스트를 수행할 수 있게 됩니다.테스트 실행 시 코드가 변경되지 않았는데도 불구하고 스크린샷이 다르게 찍히는 경우가 있었는데요, 이 문제를 해결했던 방법을 소개합니다.a. 빈 화면이 스크린샷으로 찍히는 문제테스트 페이지가 로드되기 전에 스크린샷이 찍혀 테스트가 실패하는 경우가 있었어요.Playwright에서 제공하는 {waitUntil : “networkidle”} 옵션을 사용해 네트워크 요청이 없을 때까지 기다렸지만 웹페이지 렌더링이 끝나기 전에 스크린샷이 찍히는 문제는 여전히 발생해요. 웹페이지의 렌더링이 완료될 때까지 기다린 후 스크린샷을 찍을 방법이 필요합니다.렌더링이 완

Playwright는 오픈소스 웹 테스트, 자동화 라이브러리로 MS에서 제작했습니다.Playwright 장점하나의 API로 Chromium, Firefox, WebKit까지 테스트 할 수 있습니다.관련 툴 제공 Codegen. : 작업을 기록하여 테스트를 생성. 어떤 언어로든 저장. https://playwright.dev/docs/codegen Playwright inspector: 페이지를 검사하고, 선택기를 생성하고, 테스트 실행을 단계별로 진행하고, 클릭 지점을 확인하고, 실행 로그를 탐색합니다. Trace Viewer. 테스트 실패를 조사하기 위해 모든 정보를 캡처합니다. 극작가 추적에는 테스트 실행 스크린캐스트, 라이브 DOM 스냅샷, 액션 탐색기, 테스트 소스 등이 포함됩니다. Playwright Test for VSCode : VSCode 에 plugin 을 설치하면 실행과 디버깅이 유리합니다.1.설치터미널에서 npm init playwright@latest 으로 설치합니다. TypeScript 옵션으로 설치한 예시입니다.playwright npm init playwright@latest -- -- next Getting started with writing end - to - end tests with Playwright : Initializing project in '.' ✔ Do you want to use TypeScript or JavaScript ? · TypeScript ✔ Where to put your end - to - end tests ? · tests ✔ Add a GitHub Actions workflow ? ( y / N ) · true ✔ Install Playwright browsers ( can be done manually via 'npx playwright install' ) ? ( Y / n ) · true Initializing NPM project ( npm init - y ) … Wrote to / Users / Documents / playwright / package . json : { "name" : "playwright" , "version" : "1.0.0" , "description" : "" , "main" : "index.js" , "directories" : { "test" : "test" } , "scripts" : { "test" : "echo \"Error: no test specified\" && exit 1" } , "keywords" : [ ] , "author" : "" , "license" : "ISC" } Installing Playwright Test ( npm install -- save - dev @playwright / test@next ) … added 4 packages , and audited 5 packages in 500 ms found 0 vulnerabilities Downloading browsers ( npx playwright