Testable95는 Playwright 기반 E2E 테스트 코드 생성기입니다.

테스트 코드는 프로젝트의 품질을 보장하는 데 필요하지만
작성하기 번거롭고 시간이 많이 소요됩니다.
이를 해결하고자 누구나 쉽게 테스트 코드를 생성할 수 있는 도구를 개발하였습니다.

목차

• 1️. 테스트 코드 생성하기
• 2️. 기술 스택
• 3. 기획
  • 3-1. 어떤 유형의 테스트 코드를 생성하나요?
  • 3-2. 왜 Playwright 기반 테스트인가?
  • 3-3. 누구나 쉽게 코드를 생성할 수 있는 방식
• 4. 기능 구현
  • 4-1. 블록 코딩 구현 과정
    • (1) 블록의 종류 및 역할 정의
    • (2) 블록의 위치 이동 원리
  • 4-2. 자연어 처리하기
    • (1) 자연어 처리 도구, Wit AI
    • (2) Wit AI의 이점
• 5. 협업 방식
  • 5-1. 회의록 기록
  • 5-2. PR 리뷰

1️. 테스트 코드 생성하기

2️. 기술 스택

Client

Server

Deploy

3. 기획

3-1. 어떤 유형의 테스트 코드를 생성하나요?

이 프로젝트에서는 서비스의 전체적인 흐름을 파악할 수 있는 E2E 유형의 테스트 코드를 생성합니다.

테스트는 QA엔지니어 혹은 기획자 같은 비개발자도 애플리케이션의 기능을 이해하고 그 결과가 실제 사용자 경험에 어떤 영향을 미치는지 보다 명확하게 파악할 수 있도록 돕는 도구라고 생각합니다.

그 중 실제 사용 사례에 초점을 맞추어 비개발자도 쉽게 이해하고 사용할 수 있는 테스트 시나리오를 생성할 수 있게 하는 E2E 테스트가 이 프로젝트와 가장 적합하다고 생각했습니다. 또한 사용자의 경험을 전체적으로 점검하고, 실제 사용 환경에서 애플리케이션이 어떻게 작동하는지 평가하는 E2E 테스트 생성기는 실제 협업에서 사용하기에 유용할 거라 판단했습니다.

3-2. 왜 Playwright 기반 테스트인가?

Playwright는 다양한 언어를 지원하고 병렬 처리도 가능합니다.

프로젝트에 적합한 E2E 테스트 자동화 도구를 선정하기 위해, 저희 팀은 Playwright, Selenium, 그리고 Cypress 등 주요 프레임워크들을 비교 분석하였습니다.

	Playwright	Selenium	Cypress
지원 언어	다양한 언어 지원	다양한 언어 지원	자바스크립트
병렬 처리	내장 지원	내장 지원	추가 라이브러리 설치 필요

이 중, Playwright는 자바스크립트 뿐만 아니라 다양한 프로그래밍 언어를 지원하기 때문에 사용자 각자가 선호하는 언어로 테스트 코드를 작성할 수 있게 하여, 누구나 사용할 수 있도록 접근성을 높여준다고 판단했습니다. 또한 병렬 처리를 내장 지원하기 때문에 별도 도구를 추가 설치할 필요없이 대규모 테스트 실행 시간을 단축시켜 작업의 효율성을 향상시켜준다고 생각했습니다.

GitHub Star 수 비교

또한, Playwright의 높은 스타 수는 널리 사용되고 있다고 생각했습니다. 이는 Playwright가 안정적이고 신뢰할 수 있으며, 활발한 커뮤니티 지원을 받으며 검증된 기술이라고 판단하였습니다.

이러한 근거들로 비추어 볼 때, 많은 사용자들을 보유하고 성능이 우수한 Playwright를 최종적으로 선택하게 되었습니다.

목차👆🏼

3-3. 누구나 쉽게 코드를 생성할 수 있는 방식

누구나 쉽게 코드를 생성할 수 있게 제작하기 위해 자연어를 처리하는 블록 코딩 방식을 도입하였습니다.

비개발자들에게 테스트 코드를 작성하는 데에 있어 가장 큰 장벽 중 하나는 프로그래밍 언어의 문법과 로직을 이해해야 한다는 점이라고 생각했습니다. 이러한 장벽을 허물기 위한 직관적이고 접근성을 높이는 방법을 모색하였고 자연어를 활용하는 방안을 고려하게 되었습니다. 자연어를 코드로 처리할 수 있는 방안을 모색하던 중, 저희는 스크래치(Scratch) 라는 서비스에서 영감을 받아 블록 코딩 방식을 도입하기로 결정했습니다.

스크래치는 전 세계 수백만 명의 사용자들이 그래픽 인터페이스를 통해 복잡한 코드를 작성할 필요 없이 블록을 조합하는 형태로 프로그램을 구성할 수 있는 서비스입니다.

수백만의 사람들이 사용하는 스크래치 서비스

이 프로젝트는 이러한 스크래치의 블록 코딩 원리를 적용하여, 개발자 뿐만 아니라 QA 엔지니어나 기획자도 직관적으로 코드 블록을 선택하고 조합함으로써 원하는 테스트 코드를 생성할 수 있도록 하였습니다.

목차👆🏼

4. 기능 구현

4-1. 블록 코딩 구현 과정

사용자 경험을 위해 커스터마이징하고 팀원들과 블록 코딩의 논리를 명확하게 이해하기 위해 블록 코딩을 직접 구현하였습니다.

자연어를 처리하여 코드로 변환하기 위해서는 기존의 블록 코딩과 차별점이 필요하다고 생각하였습니다. 또한 팀원들이 함께 작업하는 만큼 블록 코딩의 원리를 잘 이해해야 추후 유지보수 및 기능 확장에 도움이 될 거라 판단하였습니다. 그리하여 팀원들과 협의 후, 라이브러리를 사용하지 않고 직접 구현하는 방향으로 결정하였습니다.

(1) 블록의 종류 및 역할 정의

이 프로젝트에서는 블록을 Playwright 테스트 코드 구성 요소로 삼아 크게 세 가지 주요 유형으로 분류합니다.

1. 메서드 블록 (Method Block): 특정 기능을 수행하는 코드 조각을 의미하며, 하나 또는 여러 인풋 블록과 결합하여 사용되는 블록

2. 인풋 블록 (Input Block): 메서드 블록과 관련이 있는 세부 정보가 담긴 매개변수를 제공하는 역할로 사용자가 직접 값을 입력할 수 있는 블록

   인풋 블록
   메서드 블록

3. 라인 블록 (Line Block): 코드 한 줄을 나타내며, 하나 이상의 메서드 블록이나 인풋 블록을 포함하는 블록

   라인 블록이 생성되기 위해서는 아래 조건을 만족해야 코드 한 줄이 완성된 것으로 간주되어 다음 라인 블록을 생성할 수 있도록 구현했습니다. 다음 조건들로 사용자들이 불필요한 테스트 코드 생성을 방지하고 코드 문법이 어색한 비개발자들도 효율적으로 코드를 생성할 수 있도록 도와줍니다.

   • 하나의 메서드 블록만 존재하는 경우

     예시

     await page.waitFor();

     

   • 한 쌍의 메서드 블록과 인풋 블록이 배치되는 경우

     예시

     await page.goto("www.naver.com");

     

   • 하나의 메서드 블록과 다수의 인풋 블록이 배치되는 경우

     예시

     await page.locator("#order-sent").waitForTimeout(5000);

     

목차👆🏼

(2) 블록의 위치 이동 원리

블록의 위치를 조절하기 위해 마우스 이벤트를 통해 블록의 id를 저장하고 생성합니다. 이 후, id는 비교과정을 통해 위치를 지정하는 데 사용됩니다.

블록 코딩을 구현하기 위해 사용자의 마우스 움직임을 통해 블록의 위치를 조정해야 했습니다. 이 프로젝트에서는 드래그 앤 드롭 방식을 적용하여 사용자의 상호작용을 기반으로 블록의 id를 관리합니다. 블록의 드래그 앤 드롭 동작은 아래 세 가지 마우스 이벤트로 구성됩니다.

블록과 마우스 이벤트 연결

1. onDragStart: 사용자가 블록 드래그를 시작할 때, 드래그된 블록의 id와 그 블록이 속한 라인 블록의 id를 기록합니다.

2. onDragEnter: 사용자가 블록을 드래그하는 도중 다른 블록 위로 마우스를 이동할 때, 드롭될 위치의 블록 id와 드래그 중인 id를 실시간으로 추적합니다.

3. onDrop: 사용자가 블록을 드롭할 때, 해당 블록에 새로운 id를 부여하고, 드롭된 라인 블록의 id와 함께 이 정보를 저장합니다.

이러한 마우스 이벤트들을 통해 블록의 정보를 관리하고 블록이 놓일 위치는 정보에 담긴 id를 비교하여 결정됩니다. 블록의 위치는 onDrop 이벤트가 발생하는 시점에 id를 비교하여 아래의 조건을 통해 업데이트됩니다.

블록의 위치를 결정하는 조건

• (같은 / 다른) 라인 블록에 드롭합니다. : 드래그된 블록이 속한 라인 블록과 드롭할 라인 블록의 id를 비교합니다.
• 드롭할 위치에 다른 블록이 인접해 있나요? : 드래그된 블록과 드롭할 위치의 블록의 id를 비교합니다.

이러한 과정을 통해 조건을 설정하여 사용자들이 블록을 직관적으로 이동시킬 수 있도록 구현하였습니다. 또한 팀원들과 직접 구현하면서 프로젝트의 논리적 구성을 함께 이해하고 코드 개선에 대해 수월하게 점검하고 개선할 수 있었습니다.

목차👆🏼

4-2. 자연어 처리하기

사용자 친화성과 자연어 처리 기능을 고려하여 Wit AI를 선택하였습니다.

(1) 자연어 처리 도구, Wit AI

Wit AI는 입력된 자연어에서 의도(Intent) 와 세부 정보(Entity) 를 추출하여 자연어를 정확히 파악하고, 관련 데이터를 처리하는 자연어 처리 플랫폼입니다. 또한 개발자가 직접 의도 와 세부 정보의 연관성 를 학습시켜 원하는 목적과 관련 정보를 효과적으로 분석해주는 기능을 갖추고 있습니다.

아래의 과정을 진행하여 Wit AI의 원활한 분석을 위해 의도와 세부 정보의 연관성에 대한 학습을 진행할 수 있습니다.

의도와 세부 정보 연관성 학습

Wit AI는 이러한 학습을 통해 의도와 세부 정보의 연관성을 강화할 수 있습니다. 아래는 실제 팀원들과 "이동합니다."라는 의도와 url이라는 세부 정보의 연관성을 강화하는 학습을 진행한 자료입니다.

"이동합니다."와 url 연관성 강화 학습 기록

학습을 거친 Wit AI는 의도와 세부 정보를 아래와 같이 분석하고 추출합니다.

Wit AI의 의도와 세부 정보

1. 입력된 자연어를 통해 의도를 파악합니다.
2. 학습된 정보를 통해 의도의 이름을 추출합니다.
3. 학습된 정보를 통해 의도와 관련된 세부 정보를 파악합니다.
4. 세부 정보에 포함된 동적 값을 분석하여 의도에 필요한 값(매개변수)으로 추출합니다.

위와 같은 일련의 과정을 거쳐 Wit AI는 입력된 자연어를 의도의 이름과 세부 정보의 값을 추출하고 테스트 코드 생성에 직접적으로 활용합니다.

테스트 코드 생성 과정은 아래 예시를 통해 자세히 설명하겠습니다.

블록을 테스트 코드로 변환하는 과정

1. 사용자가 www.naver.com (url) "이동합니다." 라는 블록을 입력합니다.
2. Wit AI는 학습된 내용을 바탕으로 "이동합니다."라는 의도를 goto라는 이름으로 추출합니다.
3. Wit AI는 학습된 내용을 바탕으로 goto라는 의도와 url이라는 세부 정보와의 연관성을 파악합니다.
4. Wit AI는 사용자가 입력한 www.naver.com를 세부 정보 url의 값으로 추출합니다.
5. 세부 정보에 담긴 값(www.naver.com)과 의도의 이름(goto)를 활용하여 테스트 코드를 생성합니다.

목차👆🏼

(2) Wit AI의 이점

팀원들과 함께 Wit AI를 선택하게 된 가장 큰 이유는 사용자가 입력한 자연어 어순에 상관없이 동일하게 코드를 생성할 수 있는 이점 때문이었습니다. 블록 코딩을 할 때, 사용자는 프로그래밍 언어의 구문을 완벽히 이해하지 못할 수도 있습니다. 특히 비개발자가 테스트 코드를 작성하는 경우, 명령어의 순서를 정확히 배치하는 것이 어려울 수 있습니다.

예를 들어, 블록의 순서를 다르게 배치했지만 동일한 코드를 생성하고 싶은 두 사용자가 있습니다.

순차적 배치	역순 배치

만약 어순에 따라 다르게 자연어를 처리한다면 둘 중 하나는 에러를 발생하거나 예상치 못한 결과를 반환할거라 예상할 수 있습니다. 하지만 Wit AI는 아래와 같이 의도와 세부 정보를 키워드로 추출하기 때문에 동일한 코드를 생성할 수 있습니다.

const { intents, entities } = await witAI.message(blocks);

const intent = intents.name;
const entity = entities.value;

목차👆🏼

5. 협업 방식

5-1. 회의록 기록

회의록을 꾸준히 작성하여 추후 진행하는 작업에 도움이 되었습니다.

회의 스케줄과 기록의 꾸준한 관리는 프로젝트의 효율성을 크게 향상시키는 요소라 생각합니다. 저희 팀은 개발 기간동안 일일 스크럼과 저녁 마무리 회의를 아래와 같이 진행하였습니다.

	일일 스크럼	저녁 마무리 회의
시간	매일 오전 10시 (20분)	매일 오후 9시 (30분)
공유 내용	개인 컨디션 작업 진행 상황 당일 목표	어려움 작업 정리 익일 계획

아래는 팀원들의 일일 스크럼과 저녁 마무리 회의 진행 자료 입니다.

개발 기간 20일 동안 55개의 회의록을 작성하였습니다.

회의록을 작성하면서 팀원들과 구두로 나눈 대화는 시간이 지나면서 잊혀지기 쉽지만 기록을 통해 중요한 아이디어와 결정사항을 보존하고, 추후에 참고자료로 활용하였습니다. 또한 프로젝트에 관련된 중요 결정들이 어떤 고민과 논의를 통해 이루어졌는지 추적하고 비슷한 상황에서 의사결정을 하는데 도움을 주기도 하였습니다.

8월 5일 (E2E 테스트 프레임 워크 비교)	8월 7일 (자연어 처리 API 비교)

8월 5일 회의에서 기록한 E2E 테스트 프레임 워크를 비교한 방식을 8월 7일 자연어 처리 API 비교하는데 활용할 수 있었습니다. 이러한 회의록의 활용 방식은 팀원들의 작업 효율성을 높이는데 기여할 수 있었습니다.

목차👆🏼

5-2. PR 리뷰

수정이 필요한 리뷰는 근거 있는 자료와 링크 및 시각 자료는 반드시 첨부해야 합니다.

팀원들과의 긴 PR 리뷰 시간이 많은 어려움을 일으키는 주된 원인으로, 수정이 필요한 코드에 대해 추가 조사가 필요하다는 점을 파악했습니다. 이로 인해 리뷰 과정이 지연되고, 팀의 생산성이 저하되는 문제가 발생하였습니다.

코드 리뷰에 대한 팀원들의 어려움

이 문제를 해결하기 위해, 우리 팀은 PR 리뷰에 근거 있는 자료와 함께 시각 자료를 첨부하는 방식을 도입하였습니다.

1. 근거 있는 리뷰
   코드 수정이 필요하다고 판단되는 경우, 그 이유와 공신력 있는 근거 자료를 명확히 제시합니다.

2. 링크와 시각 자료
   관련 근거 자료를 뒷받침하는 외부 링크와 그에 해당하는 시각 자료를 첨부합니다.

아래는 개선된 리뷰 방식을 적용하기 전과 후를 비교한 자료입니다.

Before	After

이러한 리뷰 양식의 새로운 접근 방식은 팀원들이 리뷰 과정에서 발생할 수 있는 불필요한 시간 소모를 줄이고, 각 리뷰의 목적과 필요성을 명확히 이해할 수 있도록 하였습니다. 또한, 리뷰에 첨부된 시각 자료는 팀원들이 복잡한 정보를 빠르게 이해하도록 도와주며, 전반적인 작업 효율을 크게 개선하였습니다. 이러한 변화는 팀원들의 개발 프로세스의 전반적인 효율성을 높이는 데 기여했다고 생각합니다.

목차👆🏼