[테크 세미나] 시나리오 테스트와 비주얼 테스트 자동화를 통한 서비스 안정성 개선사례 소개

해당 글은 11/30 일 DEVOCEAN 에서 진행한 11월 TECH 세미나 “우아한 형제들과 함께하는 웹 프론트엔드 개발 이야기” 의 내용을 토대로 작성된 글입니다.

시나리오 테스트와 비주얼 테스트 자동화를 통한 서비스 안정성 개선사례 소개

• 유저 시나리오 기반의 자동화된 테스트 시나리오 구축

• 시각적 회귀 테스트를 이용한 프로덕트 안정성 확보

1. 소프트웨어 테스트란?

블랙박스 테스트

• 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법.

• 개발자 입장이 아닌 사용자 입장에서 소프트웨어 혹은 제품에 대한 요구사항과 결과물이 일치하는지 확인하기 위한 테스트 기법.

시나리오 테스트

• 시각적 회귀 테스트 → 해당 세미나의 주제

화이트박스 테스트

• 내부의 코드를 모두 아는 상태에서 진행

왜 블랙박스 테스트를 선택했는가?

• 화이트박스 테스트를 진행하기 위해서는, 안에 있는 모든 모듈에 대한 내용을 알고 있어야 하기 때문

2. 프론트엔드 관점에서의 테스트는 어떤것이 있을까?

위의 테스트 기법들은 공학적인 관점에서 통용되는 방법론들이다. 그렇다면 프론트엔드는 어떻게 테스트 할 수 있을까? 프론트엔드 개발자의 역할을 잘 생각해 보면 테스트의 대상을 좀 더 명확히 할 수 있다.

테스트 대상

프론트엔드에서의 테스트의 대상은 다음과 같이 크게 3가지

• 시각적 요소

• 사용자 이벤트 처리

• API 통신

을 생각해 볼 수 있다. 해당 글에서는 위의 3가지 테스트 대상 중 시각적 요소 테스트에 대한 내용으로 구성되어 있다.

• 시각적요소

• 프론트엔드 개발자는 디자이너로부터 전달받은 디자인을 보고 마크업한뒤, 컴포넌트에 스타일을 입히는 작업을 수행한다. HTML 구조가 의도한 대로 나타나는지를 테스트하기 위해 스냅샷 테스트를 수행하고, 컴포넌트가 실제로 브라우저에서 렌더링 되는 모습이 의도한 대로 나타나는지를 테스트하기 위해 시각적 회귀 테스트를 수행한다.

• 스냅샷 테스트에 사용 되는 도구로 Jest 가 대표적이고, 시각적 회귀 테스트에 사용 되는 도구로는 대표적으로 StoryBook 에서 만든 Chromatic 이 존재한다.

2-1. 그렇다면 시각적 회귀 테스트란 ?

• 코드를 바꿨음에도 화면이 다시 돌아왔는지를 테스트하는 기법이다.

• 기존의 화면 저장 + 새로운 화면을 캡처해서 → 기존과 어떤 부분이 달라졌는지 확인할 수 있는 테스트

• 즉, 내부 코드나 동작 구조가 변화 했음에도 (버전 업 이후) 같은 input 에 대해 같은 output이 나오는가를 테스트하는 기법이라고 볼 수 있다.

• 클라이언트의 비주얼 테스트를 하는 데 매우 유용함

• 시각적 회귀테스트의 목적은 무엇일까? → 기존 버전 호환성

• 앱 버전을 업데이트한 후, 원래 의도하던 웹 뷰가 잘 나오는지 확인 해야함.

• 같은 input 에 대해서 같은 output 이 나와야 한단.

• 기존에 서빙되던 페이지들이 정상적으로 서빙되는가 ? (=동일 input - 동일 output이 보장되는가?)

2-2. 시각적 회귀 테스팅 툴

Jest

• JS 테스팅 프레임워크

• 페이스북에서 만들었음.

• React, Angular, Vue 등의 프로젝트 테스트

• 비동기/병렬 테스트

• 테스트 커버리지 확인

• API mocking ..

Puppeteer

• 예시 코드

test('Target newly opened page', async () => {
        const newPagePromise = new Promise(resolve => browser.once('targetcreated', target => resolve(target.page())));
        await page.click('.repo_link');

        const newPage = await newPagePromise;
        const title = await newPage.title();
        await newPage.close();

        expect(title).toBe('GitHub - Zovi343/E2E_Testing_with_Puppeteer_Final');
    }, timeout);

Chrominum 기반 자동화 도구

• 유저 행동 코드화

• DOM 탐색 및 인터랙션

• 브라우저 다이얼로그 (alert, confirm) 상호 작용

• 실제 테스트 구성

• 모든 기능을 담은 애플리케이션 단위

• 시나리오 기반 pixel-match regression 테스트

• 행동에 끝에 나오는 화면이 기존 화면과 같은지 pixel 단위로 확인하는 테스트

3. 우아한 형제 시각적 회귀 테스팅 과정

1. 테스트용 로컬 서버 구성

2. Chromium 실행 및 초기화

3. 시나리오 수행 및 단계별 이미지 스냅샷

4. 스냅샷 비교

5. 테스트 환경

6. 도커를 통해 테스트 환경을 맞춤

4. 테스트를 도입해야 하는 이유?

• 관심있는 부분과 거리가 있는 부분 == 수동으로 테스트할 때 놓치기 쉬운 부분

• 에러방치, 기술부채, 서비스 안정성

• 찾은 에러보다 무서운건 못찾은 에러

• 테스트 코드가 없다면 ? → 레거시 코드가 일으킬 수 있는 화력을 주는 것.

• 프로덕트가 가져야되는 최소한의 안전성

• 시나리오 테스트 기반이라면 최소 품질에 대한 가이드라인을 줄 수 있다.

5. 마치며

우아한 형제들 프론트엔드에는 UNIT TEST 없다고 한다.. 오 완전의외!!

클라이언트 사이드에서는 단위 테스트를 작성하는 것에 효용이 없기 때문에

이미 작성이 안되어 있는 앱이 있기 때문 → TDD 를 작성하는 것 또한 리소스가 필요하기 때문에

비주얼 적인 부분에 더 우선순위를 두었기 때문에

우리 서비스인 팩트로이드 또한, 어떻게 보면 사용자가 화면을 띄워 놓고 모니터링하는 대시보드 툴이라고 볼 수 있기 때문에 프론트엔드 개발 관점에서는 복잡한 비즈니스 로직을 검증하기 보다는 시각적으로 의도한 화면이 나왔는지를 테스트하는 것이 더 중요할 수 있겠다는 생각이 들었다.

시각적 회귀테스트는 코드로 작성되는 UI 레벨의 제일 마지막 단계에서 프로덕트의 안정성을 확보할 수 있는 유효한 테스트이다. 다만 무작정 도입하는 것이 아니라 여러가지를 고려하며 구축, 운영에 들어가는 노력 대비 테스트가 유효한지 충분한 고민이 필요하고, 유효한 테스트 시나리오를 생각하고 파이프라인을 구축해야 이러한 효과를 크게 얻을 수 있을 것이다 !!

언젠간 테스트 코드도 작성할 수 있는 날이 오길 바라며^^,,

6. 시각적 회귀테스트 관련 참고하면 좋을 링크

• Keeping a React Design System consistent

• Visual Regression Testing

• 실용적인 프론트엔드 테스트 전략 (2)

• Visual Regression Testing

• Guide To Visual Regression Testing With Visual Testing Tools