안녕하세요, 이번 글에서는 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

Web3 세상에서는 중앙 서버가 해체되어 존재하지 않게 됩니다 (Decentralized).Web3 세상은 중앙 서버가 아니라 P2P 프로토콜에 의해 지탱됩니다.Web3 세상에서는 웹 브라우저가 플랫폼 역할을 수행할 것이라고 생각합니다.그래서 웹 프론트엔드 기술이 중요해질 것이라고 생각합니다.그런 맥락에서 Web3 프론트엔드 어플리케이션의 e2e 테스트에 대해 소개합니다.Cypress 와 Synpress 두 단어만 기억하시면 성공입니다.• None TDD (Test Driven Development) 방식으로 Web3 어플리케이션을 개발하고 있었음• None 터미널 한쪽 구석에 Unit Test를 실행시켜 놓고 소스 파일을 수정할 때마다 모든 Unit Test를 통과하는지 확인하며 개발했음• None 하지만, 모든 Unit Test를 통과했음에도 버그가 발생하는 상황을 겪음• None 서버, 네트워크, 브라우저 애드온 같은 모든 컴포넌트가 참여하는 상황에서만 확인 가능한 버그가 있었음• None 현재 많이 쓰이는 e2e 테스트 도구는 Cypress와 Selenium• None Cypress는 브라우저 안에서 일어나는 거의 모든 일을 JavaScript로 확인 가능한 개발자 친화적 도구• None 반면 Selenium은 QA 엔지니어 친화적 도구• None Web3 어플리케이션은 MetaMask 브라우저 애드온이 있어야 동작• None MetaMask 브라우저 애드온이 개입하는 사용자 시나리오를 테스트하기 위해 Synpress가 필요• None• None Cypress 구문은 assert나 command로 마무리 짓는 것이 Good Practice (assert나 command 이후에 query를 덧붙이지 않는다)• None 이더리움 메인넷을 타겟으로 하는 테스트는 Synpress의 단계에서 실패함• None Synpress가 MetaMask 애드온을 설정하고 나서 설정 성공 여부를 판정하기 위해 문구를 찾지만, 한글 브라우저에서는 이라고 표시되기 때문에 문자열 불일치로 인한 assertion fail이 발생한다• None 메인넷 대신 테스트넷을 타겟으로 테스트 시나리오를 작성하는 편이 좋다• None 모든 컴포넌트가 참여하는 상황에서만 확인할 수 있는 버그가 있음. 이를 잡아내는 것이 e2e 테스트• None Unit Test 수행 시간은 msec 단위, e2e 테스트 수행시간은 min 단위 (테스트 비용이 크다)• None 테스트 피라미드가 제시하는 바대로 e2e 테스트는 아껴 써야 함• None• None 클레이튼 dApp을 Synpress로 테스트하는 튜토리얼• None• None Cypress 테스트 구문은 query-assert 또는 query-command 체이닝 형태• None 체이닝 구문은 assert나 command로 마무리 짓는 것이 Good Practice• None• None 테스트에 있어 가장 어려운 것은 '테스트 유지/보수'• None• None 단위 테스트가 성공하더라도 실제 동작에서 오류가 발생할 수 있다•

프론트엔드 테스트 팁개요안녕하세요 벌써 병역특례 3년차! 곧 민간인이 되는 Integration Engineering 팀 윌리입니다! 본격적으로 글을 읽으시기 전에 어떤 내용인지 이 글의 성격을 알려드리려 합니다.대상비즈레버 프론트개발에 대해 궁금하신 분, 왜 다양한 프론트 테스트가 필요한지 궁금하신 분, 리액트 컴포넌트를 유닛테스트할 때 swr 때문에 고생하시는 분이 이 글을 읽으실 때 더 좋은 정보를 얻으실 것 같습니다.유닛, 통합 테스트 팁 챕터는 개발자를 대상으로 기본적인 react, javascript, typescript에 대해 알고 있는 사람을 가정하고 작성했습니다.목차는 아래와 같습니다.목차테스트의 종류 비즈레버 프론트는 어떤 테스트를 하나? 유닛, 통합 테스트 팁 테스트 라이브러리와 기초 컴포넌트 테스트 React Hook, SWR Hook 함수 테스트 타이머가 있는 경우 Hook을 쓰는 페이지 테스트 (통합 테스트) 후기: 완벽한 테스트를 위해테스트의 종류테스트의 종류타입이나 컨벤션을 잡는 정적 테스트를 제외하고 일반적으로 소프트웨어 개발에서 이야기하는 테스트는 보통 3가지를 말합니다.unit test , integration test , e2e(end to end) test 입니다.만약에 테스트에 대한 지식이 없으신 분은 차례대로 더 포괄적이고 큰 범위의 테스트를 한다 생각하시면 이해에 도움이 됩니다.저는 3가지 테스트를 게임 스타크래프트의 저그 종족에 비유하고 싶습니다. 초보인 상대를 이기기 위해서는 저글링, 히드라, 뮤탈 유닛 중 하나만 잘 사용해도 승리할 수 있지만, 중수 이상의 실력자는 3가지 유닛을 한 게임에 다 사용해야 게임에서 이길 수 있습니다.테스트도 다양한 유닛을 활용하는 저그처럼 필요에 따라 다양하게 방법을 채용하면 소프트웨어 품질을 더 잘 보증 할 수 있다고 생각합니다.unitunit은 유닛테스트, 단위테스트라고 많이들 말씀하시는데 코드에서 가장 작은 한 묶음인 함수, 클래스같은 모듈을 테스트하고 프론트엔드에서는 파일구조를 컨테이너/컴포넌트로 나눌 때 컴포넌트에 해당되는 파일에 테스트를 작성하면 유닛테스트로 봅니다. 저그 종족에서 안 뽑을 수 없는 저글링처럼 가장 기본적인 단위 테스트입니다.integrationintegration, 통합테스트는 여러 모듈끼리 연결이 있는 코드를 테스트합니다. 객체끼리 데이터를 주고받고 여러 모듈을 핸들링하는 코드의 테스트 통합테스트로 보면 됩니다. 프론트엔드에서는 파일구조를 컨테이너/컴포넌트로 나눌 때 컨테이너에 해당하는, 즉 페이지 자체를 테스트하는 코드를 짜면 여기에 해당된다 볼 수 있습니다.예를 들면 아래 같은 테스트입니다.api를 패칭 값에 따라 원하는 컴포넌트를 뿌려주고 상호작용이 잘 되는지 확인한다.e2ee2e 테스트는 end to end의 줄임말로 모듈, 코드 입장에서 품질을 보증하던 위 2가지 방법과 다르게 코드를 통해 사용자 입장에서 테스트하는 방법을 말합니다. 예시로 들면 Cypress, Selenium 같은 툴로 실제 사용자처럼 개발 환경으로 구

안녕하세요, 비즈인프라FE파트의 nina입니다. 지난 해 동료들과 함께 지식관리자센터 서비스의 프론트엔드 프로젝트에 E2E 테스트를 적용했습니다. 그 과정에서 테스팅 라이브러리 선정이나 테스트 단위 구성, Mocking 여부 등 다양한 문제들에 대해 파트 동료들과 함께 고민하면서 과제를 진행했습니다. 여기에서는 테스트 적용 중 경험한 문제와 해결 방법, 그리고 이를 통해 느낀 점에 대해 정리하겠습니다. 목표 정하기: 어떤 테스트를 만들 것인가 파트에서 유지 보수 중인 다른 Angular 프로젝트에도 이미 E2E 테스트가 적용되어 있었습니다. 하지만 테스트 실행 시 제대로 렌더(Render)가 되지 않는 상태에서 검증을 진행하는 등의 이슈가 있어 테스트가 간헐적으로 실패하는 문제가 있었습니다. 처음에는 작성된 테스트에 CI/CD를 적용하여 테스트가 성공할 때에만 Merge를 진행하도록 설정했지만, 테스트의 신뢰도가 떨어지다 보니 나중에는 테스트가 실패해도 Merge를 진행하고 있었습니다. 새로운 프로젝트에도 테스트를 적용하게 되면서, 렌더링 등 기존 테스트가 가지고 있던 이슈 해결뿐 아니라, 테스트 자체를 개선해 신뢰도 있고 의미 있는 피드백을 제공하고, 실행 시간이 빠르며, 작성 및 유지 보수에 리소스가 많이 들지 않는 테스트를 작성하는 것을 목표로 했습니다. 테스팅 라이브러리로 Cypress 선정 앞서 논의한 목표들을 실현하기 위해 적절한 테스팅 라이브러리를 선정했습니다. 기존에는 Angular에서 공식적으로 지원하는 테스팅 라이브러리인 Protractor를 사용했었는데, 2022년부터는 개발을 중단하고 Angular V15부터는 Protractor 지원을 중단한다는 소식이 있었습니다. Javascript 표준이 변경되면서 Protractor에서 제공하던 WebDriver wrapping이나 비동기 처리의 간소화 등의 기능이 더 이상 필요하지 않게 되어, 현재 Javascript 표준에 맞는 다른 테스팅 툴의 사용을 권장한다는 것이 주요 내용이었습니다.  그래서 저희는 Angular 공식 문서에서 마이그레이션을 제공하고 있는 Cypress가 저희가 사용하기에 적합한지를 리서치했습니다. 렌더 이슈 해결 가능 Cypress는 Automatic waiting을 지원하기 때문에 코드 작성에 비동기 처리가 거의 필요 없었습니다. 즉, 자동으로 같은 동작을 성공할 때까지 여러 번 반복해 결과를 얻는 방식으로 처리를 하고 있는데, 이렇게 되면 기존에 간헐적으로 렌더가 되지 않았던 문제를 해결할 수 있어 테스트 결과가 간헐적으로 실패하는 일이 줄어들고, 테스트 결과를 더 신뢰할 수 있게 됩니다. 유지 보수가 쉬운 테스트 구성 가능 기존 프로젝트의 테스트 코드는 아래처럼 모든 코드에 await가 계속 반복되고 있었습니다. it('테스트', async () => { await click(openFormButton); await fillInput(input, 'asdf'); await waitLoading(); await click(confirmButt