안녕하세요, 프론트엔드 개발자 Garden, 오소현입니다.

오늘은 프론트엔드 개발에서 왜 테스트가 필요한지, 그리고 그 중에서도 E2E 테스트 도구인 Playwright와 Cypress에 대해 자세히 알아보고자 합니다 :)

테스트 코드가 실제로 개발 과정에서 어떻게 큰 도움이 되는지, 그리고 제가 직접 경험한 Playwright와 Cypress의 장단점을 비교해보며, 왜 이러한 도구들이 프로젝트에 필수적인지를 함께 알아보려고 합니다.

또한 이러한 테스트 코드의 실질적인 이점들을 실제 사례와 함께 풀어보고, 각 테스팅 도구가 어떤 상황에서 유용하게 사용될 수 있는지, 그리고 어떤 도구가 저희 팀에게 더 적합할지 고민했던 과정을 공유합니다 ㅎㅎ

테스트코드가 처음인 분들을 위해서, 제가 생각하는 테스트 코드가 왜 필요한 지 부터 설명을 담았습니다 !

1. 테스트 코드 OnBoarding 🚀

테스트 코드, 존재를 처음 알고 들었던 생각은 “프론트엔드 개발에 왜 테스트가 필요하지? 🤔” 였습니다.

기능을 구현하고 버그가 생기면 제가 직접 확인하면 되는거지 테스트 코드를 짜야한다는 게 큰 부담이라고 생각했는데, 그 오해와 진실을 풀었던 사연을 소개합니다.

1) 테스트 코드에 대한 오해와 진실 🤫

테스트 코드는 왜 작성하기 어려울까요? 저는 테스트에 대해서 처음에 오해하고 있던게 참 많았습니다 ㅎㅎ

테스트는 발생할 수 있는 모든 버그를 다 알려주려고 짜는 게 아니다.

테스트 코드를 작성하다보면 발생할 수 있는 모든 버그를 다 알려주도록 대응하는게 좋은 테스트 코드라고 생각하지만 사실은 아닙니다. 계속해서 테스트 케이스 유형을 추가하면서 든 생각은 이미 버그를 날껄 예상하고 테스트 코드를 짜는데 그럼 애초부터 고치면 되지 않나? 라고 생각이 들었기 때문입니다.

버그를 사전에 예방하려고 많은 테스트 케이스를 작성하는데 몰입하는게 아니라, 개발자가 작성한 범위 내에서 의도한 대로 동작하는지 그 버그의 존재를 알려주도록 구현하는 것입니다.

추가로 이로 인해 찾지 못하는 버그에 대해서는 QA과정 혹은 고객들이 경험하겠지만, 그렇게 해서 발생되는 버그를 잡고 잡아간 내용을 테스트 케이스의 추가하는 방식으로 테스트 코드를 발전 시켜야합니다. 이런 경험을 통해서 “계속해서 여러 버그들을 만나서 대응력이 높아지고 → 점점 테스트할 게 줄어든다 “ 라고 목표할 것입니다.

테스트 코드를 작성할 때, 본 서비스의 코드가 수정되면 안된다.

우리가 테스트 코드를 작성할 때, 여러 테스트 케이스를 추가하면서 원래 서비스 코드를 수정하게 되는 경우가 발생할 수 있습니다. 서비스 기능으로서가 아닌, 테스트만을 위해서 저희 코드에 속성을 추가하는 것은 올바르지 않고 , 이러한 현상을 코드 오염이라고도 합니다.

저희 코드가 잘 구현 되어있다면 욕심을 내어 여러 테스트 케이스를 고려해 무리한 테스팅을 진행하지 않아도 되기 때문입니다. 테스팅의 도입 이유는 저희 서비스 코드가 발전할 수 있도록 지원하는 역할이지, 절대 배보다 배꼽이 크게 되는 상황을 만들지 않습니다.

테스트를 잘 작성하려고 해야 좋은 코드가 만들어지는 것이다.

방금 앞서서는 본 서비스의 코드를 수정하지 않는게 좋다고 했는데 이제는 테스트 코드로 인해 서비스 코드를 수정을 하는게 나을 수도 있는 경우를 살펴보겠습니다.

테스트에 대한 고민이 없이 좋은 코드가 나오기 사실 힘듭니다. 좋은 개발 설계의 조건의 되는 캡슐화와 같은 것 들은 테스트 코드를 작성할 때 쉽게 알게되기 때문입니다.

테스트 코드를 잘 작성하려고 노력하다보면 자연스레 본 코드의 개발 설계를 수정하게 됩니다. 구현하고 보니 한 번에 여러개의 기능을 구현하고 있다면 한 가지의 기능을 가질 수 있도록 분리하거나, 함수 1개로 기능을 표현하는 등의 더 좋은 방향으로 개발 설계를 수정할 수 있습니다.

지금까지 제가 예전에 테스트에 대해 오해하고 있던 사실을 풀었던 사연과, 테스트 코드를 작성하며 깨달았던 점을 함께 알아보았습니다. 이제는 제가 사내에 테스트 코드를 도입하려고 하는 배경과 그 목적을 알아보겠습니다.

2) 우리 팀에 도입하려고 하는 이유?

QA 시간을 줄이고, 사용자들의 불편함을 줄여 계속해서 블링을 사용하도록 만든다.

저희 팀은 사용자와 맞닿아있는 서비스 최앞단의 개발 팀입니다. ⭐ 저희 서비스에서 사용자 버그가 생기면 거의 저희팀에 먼저 업무 요청이 오게되니까요 ;) 고객들이 사용하면서 불편함이 생기면 저희에게 전화 혹은 이메일로도 계속해서 불만을 접수하게 될 것입니다… 따라서 저는 테스트가 저희 팀에 필요한 요소 중에 하나라고 생각했습니다.

기존 기능 (인증, 결제 부터) 부터 앞으로 새로 개발되는 기능들을 배포하고 나서도 버그는 계속해서 발생할 수 있습니다. 우리는 현재 QA에서 보고되는 에러들을 쭉 보고 비슷한 에러 유형을 묶어 패턴을 찾아 추후에 새로 개발 되는 기능들에도 개발하면서 미리 대응하는 등의 방식으로 QA에 투자되는 시간을 줄이고 싶습니다.

에러를 뒤늦게 발견할 수록 우리가 그 에러를 해결하는데 드는 비용은 급격히 증가합니다. 개발 중에 문제를 발견하면 바로 수정하고 고치면 되지만 개발이 완료된 뒤에 에러가 발생하는것은 원인을 쉽게 찾기 힘듭니다. 이게 심각하면 기획부터 다시해서 코드를 새로짜야하는 일이 발생할 수 있습니다.

개발에서 먼저 테스트를 도입해 고객들이 서비스를 사용하면서 발생하는 에러( 서비스 에러, 인증이나 결제 부분)을 최대한 줄여서 배포해 계속해서 블링을 사용하도록 만들고 싶습니다. 이게 제가 생각하는 저희 팀의 테스트 도입 그 첫 번째 이유입니다.

사내 코드 품질을 높이기 위한다.

테스팅 주도 설계 ( TDD )라는 테스트 개발론을 들어보셨나요? 애시당초 신 기능을 개발 할때 부터 이 기능에 대한 여러 테스트 케이스를 미리 생각하고 기능 개발보다 먼저 테스트 케이스 부터 작성하고 개발하는 방법론을 뜻합니다. 말로만 들어도 시간이 너무 오래걸리고 생산성이 낮아 비효율적일 것 같은데 이러한 방법론이 왜 생겨나게 된 것일까요? 바로 테스트를 고려하면서 개발하는 것이 얼마나 중요한지 알려주는 이론입니다.

저는 TDD까지는 말고, 저희가 한 기능을 새로 개발할 때 여러 발생할 수 있는 테스트 케이스 유형을 고민해보면서 개발을 진행한다면 자연스레 더 나은 설계가 가능하고, 이렇게 모두가 고민하면 의도하지 않아도 자연스레 코드 품질이 높아질 것이라 기대합니다.

우리는 많은 시간을 투자해서 개발을 하면 더 많이 개발을 할 수 있을 것이라고 보통 생각하게 되는데 이러한 생각을 바탕으로 한다면 더 열심히만 일하게 될 것입니다… 나 대신해서 발생하는 버그를 누군가는 해결해야해서 문제가 더 많이 생기고 이 문제로 인해 일이 더 밀리게 될 것 같습니다.. 이런 경우를 막고 싶습니다.

우리는 테스팅을 도입해서 내 코드에 자신감을 가지고 지속적인 리팩토링과 적극적인 기술 부채 상환을 이루어 내기 위해 노력해야합니다.

3) 프론트엔드 테스트의 모든 것.

지금까지 테스트를 왜 도입해야하는 가를 알았다면 이제는 프론트엔드 테스트에는 뭐가 있는지 그 개념적인 것을 공부해보겠습니다. 따로 기술 블로그에 작성해두었으니 아래의 글을 참고해주세요!

[인턴일지] 프론트엔드 개발에서 테스트가 필요한가요?

2. Cypress vs Playwright 비교

1) 각 특징 별로 한눈에 알아보기!

기능/특성	Cypress	Playwright
지원 서비스	웹 브라우저만 가능	웹 브라우저, 모바일(iOS/Android) 모두 가능
비용	테스트 러너는 무료 / 대시보드는 유료	전 기능 무료
로컬 설치 및 자동화 셋업	로컬 설치는 쉬운 편, 자동화 파이프라인 구축은 무난한 편	로컬 설치 무난한 편, 자동화 파이프라인 구축은 쉬운 편
지원 언어	JS, TS (최적화 잘됨)	JS, TS, JAVA, Python, C#
브라우저	사파리 지원 안 함	Chromium, Firefox, Safari 등 지원 다 함
속도	Playwright 보다 느림, 병렬적 실행은 sorry-cypress 외부 라이브러리 필요 or 비용 지불	병렬적 실행 지원해서 한 테스트 단위는 빠른 편, 자동화 속도는 Cypress보다 느림
디버깅	엄청 좋음 굿굿	무난한 편, 있을 건 다 있음
개발 QA 지원	지원함	지원함
리소스	방대함	Cypress에 대비해 절대적으로 부족함

현재 테스트 생태계에서 Cypress의 점유율이 압도적으로 높아서 저도 e2e 테스트 도구 == Cypress라고 생각했었는데 이와 쟁쟁한 새로운 툴의 존재를 알게 되어서 신기했습니다 (고르기 참 애매합니다)

이론만으로는 절대적으로 감도 안오고 참 애매해서 저는 실제 프로젝트에 Playwright도 도입해보기로 했습니다.

2) 테스트 코드 비교 (문법, 예외처리)

우선 테스트를 진행하려면 각각 테스트 코드를 구현해야겠죠? 그래서 같은 테스트를 진행하는 테스트 코드를 한번 나란히 비교해보았습니다. 이번에는 특히 문법적인 요소를 집중해서 살펴봅시다.

(1) Cypress 테스트 코드

// Cypress의 기본 구조를 사용한다.
describe('Todo List', () => {
  // beforeEach를 사용해 각 테스트가 시작되기 전에 실행될 코드를 정의한다.
  beforeEach(() => {
    // 'cy.visit'을 사용해 테스트할 페이지로 이동한다.
    cy.visit('https://playwright-testing-xi.vercel.app/vling/index.html');
  });

  it('할일 목록을 추가해본다.', () => {
    // 'cy.get'을 사용해 요소를 찾고, 'cy.type'으로 텍스트를 입력한다. 
    cy.get('#new-todo').type('정원이랑 놀기');
    // 'cy.contains'로 버튼을 찾고 'cy.click'으로 클릭한다.
    cy.contains('Add').click();

    // 'cy.get'과 'should'를 사용해 특정 텍스트가 페이지에 있는지 확인한다.
    cy.get('#todo-list li').first().should('have.text', '정원이랑 놀기');

    // 두 번째 항목 추가
    cy.get('#new-todo').type('정원이랑 성수동 가기');
    cy.contains('Add').click();

    // 두 개의 항목이 목록에 있는지 확인한다.
    cy.get('#todo-list li').eq(0).should('have.text', '정원이랑 놀기');
    cy.get('#todo-list li').eq(1).should('have.text', '정원이랑 성수동 가기');
  });

  it('should allow me to toggle todo completion', () => {
    // 항목 추가
    cy.get('#new-todo').type('write Playwright test{enter}');

    // 'cy.get'과 'click'으로 항목을 클릭하여 완료로 표시한다.
    cy.get('#todo-list li').first().click();

    // 'should'와 'have.class'를 사용해 클래스가 변경되었는지 확인한다. 
    cy.get('#todo-list li').first().should('have.class', 'completed');
  });
});

(2) Playwright 테스트 코드

const { test, expect } = require('@playwright/test');

test.describe('Todo List', () => {
    test.beforeEach(async ({ page }) => {
        await page.goto('https://playwright-testing-xi.vercel.app/vling/index.html');
    });

    test('할일 목록을 추가해본다.', async ({ page }) => {
        //1. 할 일 입력 필드와 추가 버튼을 찾는다. 
        const newTodo = page.locator('#new-todo');
        const addTodoButton = page.locator('#add-todo');

        //2. 할 일을 입력하고 추가해본다.
        await newTodo.fill('정원이랑 놀기');
        await addTodoButton.click();

        //3. 할 일 목록에 할 일이 추가되었는지 확인해본다.
        await expect(page.locator('#todo-list li')).toHaveText([
            '정원이랑 놀기'
        ]);

        //4. 두 번째로 할 일을 추가해본다. 
        await newTodo.fill('정원이랑 성수동 가기');
        await addTodoButton.click();

        //5. 할 일 목록에 두 개의 할일 목록이 추가 되었는지 확인해본다. 
        await expect(page.locator('#todo-list li')).toHaveText([
            '정원이랑 놀기',
            '정원이랑 성수동 가기'
        ]);
    });

    test('should allow me to toggle todo completion', async ({ page }) => {
        const newTodo = page.locator('#new-todo');
        const addTodoButton = page.locator('#add-todo');

        // 1. 할 일을 추가해본다.
        await newTodo.fill('write Playwright test');
        await addTodoButton.click();

        //2. 할 일 항목을 클릭하여 완료로 표시해본다. 
        const todoItem = page.locator('#todo-list li').first();
        await todoItem.click();

        //3. 할 일 항목이 완료로 표시되었는지 확인해본다.
        await expect(todoItem).toHaveClass(/completed/);
    });
});

저는 개인적으로 Playwright가 기존 자바스크립트와 구현 문법이 유사해서 더 쓰기가 수월했습니다.

cypress로 다양한 e2e 시나리오를 구현하려면 여러 추가적인 확장 문법을 사용해야하지만,

playwright는 단순하고, 테스트 코드 문법을 몰라도 어떻게 테스트 하는지 흐름을 파악하기 쉬웠습니다.

3) 로컬 환경에서의 테스트 비교 👤

이제 본격적으로 Cypress와 Playwright를 nodejs(로컬 환경)에서 테스트되는 과정을 비교해보겠습니다.

(1) Cypress 로컬에서 실행

Cypress에서 e2e 선택하기	테스트 실행화면

• Cypress는 VSC에서 확인하는 것이 아니고, 테스트를 실행하면 Postman 처럼 테스팅 확장 도구 익스텐션이 열리게 됩니다. 이렇게 모든 테스트 경우를 확인하게 됩니다.
• 그리고 컴포넌트 별 단위 테스팅 옵션과 E2E 테스팅 옵션을 별도로 분리하여 각각 테스트하기 좋도록 지원하고 있습니다.
• 그리고 빗버킷이나 깃허브 처럼 팀으로 대시보드를 운영할 수 있고 그 팀에 레포들을 한 대시보드에서 테스트 할 수 있도록 지원합니다 → 요게 이제 유료 입니다.

(2) Playwright 로컬에서 실행

먼저, Playwright은 로컬에서 설치하기 가장 편리했습니다 bb

또한 Playwright는 다음과 같은 이점들을 제공합니다.

확장 플러그인	UI 대시보드로도 테스팅

특히 해당 대시 보드 화면에서 클릭하는 시점에 어디를 누르고 있는지도 알려주게 됩니다.

(3) 정리 ⭐

• 저는 로컬환경에서는 둘다 비슷하다고 생각합니다. 누구 하나 돋보이는 장점은 없고, 로컬에서 테스트 환경 세팅하는 것도 쉬웠습니다.
• 하지만 테스트 시간은 Playwright가 더 빨랐습니다.
• VSC 내에서 테스트를 돌리고 바로 확인하면 되는 Playwright가 개인적으로 더 좋았습니다
• 테스트 코드를 실행시키는 워크플로우 구조부분에서는 Playwright가 간편했습니다
  • yaml 파일에 경로만 바꿔서 지정해주면 되었기 때문입니다.

4. 테스트 자동화 비교 👥

저희 회사는 Bitbucket으로 사내 코드를 관리하고 있는데요!

더 궁금하시다면 [240109 인턴일지] Bitbucket? 그게 뭐죠? Github랑 뭐가 다른가요?글을 참고하시면 됩니다 :)

Bitbucket 파이프라인에서도 제대로 작동하고, 쓰기 사용한지 체크를 진행해보았습니다 :)

1) Cypress 빗버킷 자동화 파이프라인 구축

• Cypress로 빗버킷 레포 단위의 자동화 파이프라인을 구축할 수 있었습니다. (빗버킷 지원함)
• 각 테스트 유형 별로 E2E , 컴포넌트 테스트 워크플로우 파일을 각각 만들어줘야하는 번거로움이 있었습니다.

image: cypress/base:20.9.0

e2e: &e2e
  name: E2E tests
  caches:
    - node
    - cypress
  script:
    - npm run dev --scope=exportStaticExample &
    - npm run e2e:record -- --parallel --group UI-Chrome --ci-build-id $17ff0169-07f2-48f2-99ae-03018cfd538f
  artifacts:
    # store any generates images and videos as artifacts
    - cypress/screenshots/**
    - cypress/videos/**

pipelines:
  default:
    - step:
        name: Install dependencies
        caches:
          - npm
          - cypress
          - node
        script:
          - npm ci
    - parallel:
        # run N steps in parallel
        - step:
            <<: *e2e
        - step:
            <<: *e2e
        - step:
            <<: *e2e
definitions:
  caches:
    npm: $HOME/.npm
    cypress: $HOME/.cache/Cypress

로컬 포트로(배포 url)도 테스트 자동화가 가능했습니다.

2) Playwright 빗버킷 자동화 파이프라인 구축

• Playwright은 테스트 자동화를 적극적으로 지원합니다. 특히 깃액션을 자동으로 파이프라인을 잡아줍니다.
• 간단하게 프로젝트를 세팅하고 제 깃허브 레포에 올려서 깃 액션으로 자동화를 연습했습니다.

• Playwright는 특히 url로 화면을 찾아서 e2e 테스트를 진행하는데, 이때 처음에 로컬 url을 못찾는 이슈가 있었으나 아예 워크플로우에 로컬 서버를 실행시키는 명령어까지 다 넣어줘야 잘 찾는 모습을 보여줬습니다.

---

• 빗버킷 파이프라인과 연동이 안될까봐 걱정했는데 다행이도 워크플로우 yaml 세팅에 신경써줘서 자동화 파이프라인을 구축하는데 성공했습니다.
  

3) 정리 ⭐

• Cypress는 빗버킷을 지원해서 자동화 구축 난이도가 수월했으나, Playwright는 깃액션은 잘해주지만 빗버킷에 약간의 러닝 커브가 있었습니다.
• 다행이도 둘다 빗버킷에서 자동화 시스템 구축에 성공했습니다 깃액션까지 안가도 될 것 같아요!
• 자동화 측면에서는 Cypress가 더 수월했습니다.

5. 테스팅 속도 최적화(병렬적 테스트 지원)

테스트 코드를 짜는 것도 시간이 걸리는데 테스트 속도까지 느리면 더 하기 싫을 것 같았습니다.

그래서 여러 테스트를 동시에 돌려주는 병렬적 테스팅 환경을 지원해주는 지가 중요했습니다.

1) Cypress 병렬 실행 지원 여부

우선 Cypress에 병렬적으로 실행하도록 기능은 최근에 추가 되었으나 공식 문서에서도 성능 저하로 권장하지 않고 있는데 이게 심지어 유료 입니다 ^^….

그래서 Sorry-Cypress 라는 확장 프로그램을 사용하면 병렬처리가 가능해진다고 합니다. 하지만 외부 플러그인을 끼워 쓰는 만큼 병렬 실행 할때마다 워크플로우 마다 번거로운 설정을 해주어야 합니다.

2) Playwright 병렬 실행 지원 여부

Playwright는 무료로 테스트들을 병렬적으로 실행하도록 지원합니다.

설정 하는 것도 정말 간단했어요, config.json 파일에 몇개를 같이 테스트할건지 개수만 확인해서 넣어주면 되었으니까요! 😆

/**
 * @see https://playwright.dev/docs/test-configuration
 */
module.exports = defineConfig({
  testDir: './vling',
  /* Run tests in files in parallel */
  fullyParallel: true,
  /* Fail the build on CI if you accidentally left test.only in the source code. */
  forbidOnly: !!process.env.CI,
  /* Retry on CI only */
  retries: process.env.CI ? 2 : 0,
  /* Opt out of parallel tests on CI. */
  workers: process.env.CI ? 5 : undefined, //이 부분입니다.
  /* Reporter to use. See https://playwright.dev/docs/test-reporters */
  reporter: 'html',
  /* Shared settings for all the projects below. See https://playwright.dev/docs/api/class-testoptions. */
  use: {
    baseURL: 'http://localhost:3000/vling', // 로컬 서버의 URL
    trace: 'on-first-retry',
  },

자동화에서도 한번 실제 병렬적으로 동시에 테스트 되는지 확인해볼까요?

원래 같았으면 CI 설정까지 5분이상 걸리는 테스트 였지만 1분 26초대로 줄였습니다 굿굿!!

3) 정리 ⭐

병렬적으로 테스트를 동시에 실행시켜 테스트 속도를 줄이는 것은 매우 큰 이점으로 작용됩니다.

테스팅에 소요되는 시간을 절대적으로 줄여주기에 애초부터 시나리오가 길어 테스트가 오래 걸리는 E2E 테스트에 도입하기 가장 적합하다고 생각합니다.

위의 이유로 병렬적으로 테스트를 할 수 있다는 점에서 Playwright가 더 나은 것 같습니다.

6. 명확한 이점 요약 정리 ⭐

자 이제 다 왔습니다. 저는 테스팅 툴을 마지막까지 고민하면서 4가지의 기준으로 테스팅 툴을 결정하고 싶었습니다. 직접 도입해서보면서 느꼈던 점과 아래의 판단 기준으로 생각해 보겠습니다.

• 러닝 커브
• 현재 도입 시 이점
• 추후 테스트 자동화 대상 기능 범위를 점차 늘렸을 때의 충분한 커버 가능성
• 각 기술 자체의 업데이트 가능성
  • 중간에 서비스 지원 중단 가능성이 있는가?
  • 타 회사에서 많이 사용하고 있는가 → 기술 블로그나 사례로 관련 내용 확인
  • 특히 타 회사에서 Cypress를 쓰다가 Playwright로 넘어간 케이스 위주 검토

1) 러닝 커브

• 자동화 구축 : Cypress << Playwright
• 테스트 코드 작성 : Cypress >> Playwright
• 테스트 코드 파악 (가독성) : Cypress >> Playwright

자동화 구축은 테스트 업무를 맡은 제가 진행할 예정이기 때문에 팀 내에서는 테스트 코드 작성 및 구현이 수월할 Playwright가 러닝 커브가 더 낮다고 생각했습니다.

2) 현재 도입 시 이점

저는 최대한 팀 내에서 테스트 코드 부담을 줄이고 싶습니다. 따라서 다른 확장 내장 프로그램을 사용하지 않고 VSC에서 모든 것을 해결할 수 있는 Playwright가 더 간단하고 테스트 하기 쉽다고 생각합니다.

그리고 현재 배포를 수동으로 커맨드에서 명령어로 실행하고 있기 때문에 수동적 테스트에 더 유리한 Playwright 가 더 좋다고 생각했습니다.

또한 단위테스트를 먼저 도입하는게 아니고 E2E 테스트를 먼저 도입할 예정이기에 테스트 시간이 오래 걸릴 것이고 병렬적으로 지원하는 Playwright가 더 나은 것 같습니다.

3) 추후 커버 가능성

둘 다 단위테스트 범위까지 확장해서 내려가도 충분히 커버할 수 있을 것이라고 생각했습니다 🙂

4) 각 기술 자체의 업데이트 가능성

우선 현재 테스트 시장에서 60% 이상은 Cypress를 쓰고 있고 Playwright은 라이징 스타인 것으로 보입니다.

🤔 테스트 생태계 자체도 작은데 ,, 레퍼런스가 Cypress가 압도적으로 높습니다.

하지만 대규모 서비스 회사의 기술 블로그를 다 뜯어본 결과 테스트 성능 문제로 Cypress → Playwright 로 바꾸는 회사 자료가 많아졌습니다.

7. 우리 회사에서는요,, ❤️

저는 위의 많은 기술 검토 끝에 Playwright로 현재 e2e 테스트를 진행하고 있습니다
제가 직접 정하고 진행하다보니 애착이 많이 생기더라고요 ㅎㅎ Playwright를 아주 잘 쓰고 있습니다 bb 직접 Playwright에 오픈소스 기여도 몇 차례 진행하고 bb 저에게는 가장 자주 사용하고 있는 테스트 코드 툴이 되었습니다 ㅎㅎ 다음 포스팅에서는 직접 도입기로 찾아뵙겠습니다 :)