test 5

토스 테스트 자동화 플랫폼 구축 영상 요약

개요현재 직장에서 puppeteer기반 cypress 문법을 사용하는 e2e 테스트 프레임워크를 개발하고 있는데 알고리즘의 선택인지 우연인지는 모르겠지만 토스에서 비슷한 것을 만들고 발표한 영상이 눈에 들어오게 되었고 관심이 생겨 해당 영상을 꼼꼼히 보고 요약한 내용이다. 테스트 자동화 플랫폼을 만드는 목적이 다 같아서 그런건지 사람 생각이 다 거기서 거기라서 그런건지 cypress, playwright와 같은 타 테스트 프레임워크를 사용하지 않고 puppeteer 기반으로 테스트 프레임워크를 직접 만든다는 큰 차이를 제외하고는 많은 부분의 플랫폼 설계가 비슷하여 좀 신기했다.  e2e 플랫폼을 만든다는 큰 목적을 가지고 구조와 흐름을 설계하게 되면 결국 누가 만들던간에 이런 느낌으로 완성이 되지 않을까..

frontend 2025.01.07

Cypress의 단점을 극복하기 위한 puppeteer 기반의 e2e 테스트 프레임워크 개발(2)

https://jjongsk.tistory.com/entry/Cypress%EC%9D%98-%EB%8B%A8%EC%A0%90%EC%9D%84-%EA%B7%B9%EB%B3%B5%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-Puppeteer-%EA%B8%B0%EB%B0%98-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%EA%B5%AC%ED%98%841 Cypress의 단점을 극복하기 위한 puppeteer 기반의 e2e 테스트 모듈 구현(1)개요 e2e 테스트 라이브러리가 필요하여 cypress에 대해 분석하다가 이를 사용하는 것은 현재 구조에서 불가능하다고 판단하여 puppeteer를 사용하여 e2e 테스트 아키텍쳐를 직접 구현하기로 결정하jjongsk.tist..

frontend 2024.12.20

Cypress의 단점을 극복하기 위한 puppeteer 기반의 e2e 테스트 프레임워크 개발(1)

개요 e2e 테스트 라이브러리가 필요하여 cypress에 대해 분석하다가 이를 사용하는 것은 현재 구조에서 불가능하다고 판단하여 puppeteer를 사용하여 e2e 테스트 아키텍쳐를 직접 구현하기로 결정하였다. cypress를 사용하는 것이 불가능한 이유는 아래와 같다.cypress의 너무 느린 속도불가능한 유지보수불가능한 병렬처리쉽지않은 커스텀특히 1번 속도 문제가 너무 심각하였다. 하지만 cypress에서 제공하는 테스트 코드 문법, 여러가지 e2e 기능은 충분한 가치가 있었기에 cypress의 특정 기능을 비개발자(qa,qc 등)가 사용할 수 있도록 cypress 인터페이스를 유지하면서 테스트를 실행할 수 있는 솔루션을 만드는게 이번 프로젝트의 핵심 목표이다. cypress의 테스트 코드는 문법은 ..

frontend 2024.12.16

프론트엔드 전체 테스트 환경 구축해보기(1.설계)

개발 목표현재 회사의 테스트 코드는 작성은 잘 되어 있지만 이를 실행하는 환경이 너무 느려 모든 테스트를 한 번 실행하는데 수십분 길면 한 시간이 넘는 시간이 걸린다. 심지어 제대로 전역으로 테스트를 실행하는 로직도 없어 사실상 유닛 테스트를 여러 번 실행하는 느낌으로 동작하고 있다. 약 1~2주 정도 타임라인을 잡고 단위 테스트, 전체 테스트를 빠르게, 테스트 코드 개발자가 편하게 작성할 수 있도록 하는것이 목표로 개발을 진행할 예정이다. 아래는 기획, 설계에 앞서 정리한 개발 요구사항이다.CLI로 실행 가능해야한다. ex)ecDev testRun —path테스트 파일에서 F6과 같이 shorcut 입력 시 동작해야한다.백그라운드에 테스트를 위한 웹 서버 실행스토리북 서버: 스토리북 UI에서 단순 클릭..

frontend 2024.08.22

기존 빌더와의 호환성 검증을 위한 통합 테스트코드 작성

개요최근 레포지토리가 점점 커지면서 파일의 증가로 인해 전체 빌드 시 간간히 메모리 초과 문제가 발생하여, 빌드 시스템을 리팩토링하는 작업을 진행하였다. 이 빌더는 약 150명의 개발자가 사용하는 회사 전체 프로젝트 배포에 사용되므로, 기존 빌더와의 완벽한 호환성을 유지하는 것이 1순위 목표였고 개발 자체는 후순위였다. 따라서, 테스트 코드를 통해 기존 빌더와의 동기화 유무를 확실하게 잡고 개발을 시작하기로 하였다. 빌더는 내부에서 child_process를 사용하여 멀티 프로세서 환경에서 tsc를 사용한 컴파일과 rollup을 사용한 번들링 과정을 거쳐 빌드 파일을 생성하는 방식으로 동작하고 있었다. 단위 테스트보다는 결과 파일이 동일한지를 확인하는 것이 중요했기 때문에 빌더를 실행 시킨 뒤 최종 결과..

etc 2024.07.03