사용자를 위한 Playwright E2E 테스트

안녕하세요. 프롬 스토어 팀에서 테스트와 애자일을 전도하는 프론트엔드 개발자 김태희입니다.

어느덧 제가 팀에 들어온지 4개월이 지났습니다. 새 기능을 만들 때에 자동화 테스트는 거의 필수가 되었습니다. 배포 전 QA에서 나오는 에러는 줄어들었고, 남아 있는 (모바일 사파리 같은) 엣지 케이스들도 패턴을 찾아 예방하려 노력 중 입니다.

오늘은 playwright를 이용해 실무에서 e2e 테스트를 만들어가는 과정을 소개해보려 합니다. 저희 팀에 e2e 테스트를 도입하면서 겪은 시행착오를 토대로, 처음 테스트를 작성하는 분들이 자주 하는 실수들도 다룹니다.

수동 e2e 테스트를 자동화하기

물론 자동화부터 시작하는 건 좋은 일이 아닙니다. 보통 테스팅 도구는 나름의 사용법이나 암시적인 동작들이 있어서 처음에는 좌절하기 쉽습니다. 분명 손으로 하면 되는데, 자동화 테스트는 뭔가 꼬여서 안 되는 불쾌한 경험을 하다보면 테스트를 포기하기 쉽습니다.

그래서 수동 테스트를 체계적으로 하는 것부터 시작하시길 권합니다. 테스트에서 (더 잘, 더 자주) 배우기에서도 이야기한 것처럼, 기획서를 검토할 때부터 케이스를 다양하게 생각해보고 작성하는 게 중요합니다. 특히 주먹구구식 테스트에서 체계적인 탐색적 테스트를 할 수 있도록 에러와 테스트 케이스에 대한 이해를 높여야 합니다. 예상치 못한 케이스를 만날 때마다 패턴을 찾고 프로세스를 개선해 나가야 합니다.

playwright를 이용한 e2e 테스트로 시작하는 이유도, 수동 테스트와 여러모로 닮아 있기 때문입니다. 당연히 귀찮은 단점과 장점을 공유하기도 합니다. 그래서 한 단계 한 단계 수동 테스트와 자동 테스트를 비교해가면서 이야기를 해보겠습니다.

마이크로소프트의 오픈소스 E2E 자동화 도구 Playwright

테스트에 대한 책들을 보면 값비싼 e2e 테스트 솔루션들을 비판하는 말들이 많습니다. 다행히 Playwright는 마이크로소프트에서 만든 오픈소스 프로그램으로, 누구나 쉽게 사용할 수 있습니다. JS 뿐만 아니라 Python 과 Java 등 다양한 언어를 지원하지요.

비슷한 솔루션으로 Cypress를 사용 중이시거나, 들어보셨던 분도 계실 겁니다. 저 역시 과거에 Cypress를 사용했었습니다. Cypress도 여러모로 장점이 있지만. Playwright가 test 속도도 더 빠르고, 다양한 브라우저를 지원하며, 접근성에 기반한 강력한 기능들을 제공합니다. 재미있게도 Cypress도 Playwright를 이용해서 Safari를 지원하고 있을 정도입니다.

playwright를 설치하는 건 어렵지 않습니다. vs code extension도 있고요. e2e의 특성상 어떤 UI 프레임워크를 쓰는지도 상관 없습니다. 다들 playwright를 사용하기로 결정하시고, 설치도 마치셨다고 전제하고 이야기를 계속해보겠습니다. package.json에 다음처럼 scripts를 추가해두시면 유용합니다. 특히 ui 모드에서는 편리하게 각 단계의 스냅샷과 로그를 보실 수 있어서 여러모로 편리합니다. 재생 버튼만 누르면 테스트를 실행할 수 있죠.

// package.json
{
    // ...
    "scripts": {
        // ...
        "e2e": "playwright test", // 기본은 헤드리스 모드라 브라우저가 백그라운드에서 안 보입니다. 
        "e2e:headed": "playwright test --headed", // headed 플래그를 걸면 브라우저가 보입니다
        "e2e:ui": "playwright test --ui" // 편리한 UI를 볼 수 있고, --headed까지 쓰면 브라우저도 같이 보입니다.
    }
    // ...
}

사용자 입장에서 시나리오 만들기

test를 짤 때에는 다양한 케이스를 생각해보고, 사용자 입장에서 시나리오를 만듭니다. e2e는 보통 치밀하게 모든 케이스를 테스트하진 않습니다. 경우의 수가 많다면 e2e가 아니라 component나 unit test로 분리할 수 없을지 고민해보는 게 좋고, 특히 외부 의존성과 부수효과가 없는 순수 함수나 객체를 분리하는 게 좋습니다. (추후에 다른 글에서 더 자세히 다룰 예정입니다)

거꾸로 말하면 e2e 테스트는 되도록 실제 외부 의존성과 부수효과까지 함께 테스트하는 게 좋습니다. 실제 브라우저에서, 실제 (와 최대한 유사한) api로 테스트를 하면, 프런트엔드 뿐만 아니라 여러 의존성의 문제까지 함께 찾아낼 수 있습니다.

로그인 하지 않은 채로 상품을 구매하려 하면 로그인을 요구하고, 로그인하면, 보던 상품으로 돌아간다

전에도 로그인 기획 분석을 해봤었는데요. 상품을 구매하려면 로그인이 필요합니다. 그래서 구매하기 버튼을 누르면 로그인을 요청하는데요. 로그인한 뒤에 보고 있던 상품이 아니라 홈페이지로 돌아가면 사용자는 당황할 것입니다… 로그인한 뒤에 보고 있던 상품 페이지로 돌아오는 시나리오를 playwright로 자동화해 보겠습니다.

Given 로그인하지 않은 채로
When 상품을 구매하려 하면
Then 로그인할지 AlertDialog로 물어본다
When 확인을 누르면
Then 로그인 페이지로 이동한다
When 로그인을 완료하면
Then 상품 페이지로 돌아온다

접근성으로 요소 찾기

접근성이 이끄는 웹 프론트엔드 테스트 자동화에서 이야기한 것처럼, 접근성 표준을 활용하면 모든 사용자에게 편리하면서도 테스트하기 쉬운 앱을 만들 수 있습니다.

위의 케이스를 접근성 요소로 구체화하면 다음처럼 번역할 수 있습니다.

로그인하지 않은 채로
"상품 페이지"로 이동해서

"구매하기" [button]을 클릭하면
"로그인" [alertdialog]로 물어본다

"확인"[button]을 클릭하면
"로그인 페이지"로 이동된다

"fromm 통합 ID"[textbox]에 "test@wonderwall.kr"을 입력하고
"비밀번호"[textbox]에 "1q2w3e4r"을 입력하고
"로그인"[button]을 클릭하면
상품 페이지로 돌아온다

playwright 코드로는 다음과 같이 쓰면 됩니다. 이제부터 이 코드를 하나씩 뜯어보겠습니다.

test('로그인 하지 않은 채로 상품을 구매하려 하면 로그인을 요구하고, 로그인하면, 보던 상품으로 돌아간다', async ({ page }) => {
    // Given "상품 페이지"로 이동해서
    await page.goto(`${CLIENT_HOST}/goods/275`);

    // When "구매하기" [button]을 클릭하면
    await page.getByRole('button', { name: '구매하기' }).click();

    // Then "로그인" [alertdialog]로 물어본다
    const alertDialog = page.getByRole('alertdialog', { name: '로그인' });
    // When "확인"[button]을 클릭하면
    await alertDialog.getByRole('button', { name: '확인' }).click();

    // Then "로그인 페이지"로 이동한다
    const form = page.getByRole('form', { name: '로그인' });
    // 폼이 보일 때까지 기다립니다
    await form.waitFor();

    // When "fromm 통합 ID"[textbox]에 "test@wonderwall.kr"을 입력하고
    await form.getByLabel('fromm 통합 ID').fill('taehee.kim@wonderwall.kr');
    // When "비밀번호"[textbox]에 "1q2w3e4r"을 입력하고
    await form.getByLabel('비밀번호').fill('wonderwall2@');

    // When "로그인"[button]을 클릭하면
    await form.getByRole('button', { name: '로그인' }).click();

    // Then 시작했던 상품 페이지로 돌아온다
    await page.getByRole('heading', { name: '상세페이지' }).waitFor();
    await expect(page).toHaveURL(/.*\/goods\/275/);
})

locator와 사용자의 action

page.getByRole과 같은 playwright의 locator는 testing-library와 비슷하게 생겼습니다. 하지만 element를 반환하는 테스팅 라이브러리와 달리, lazy하다는 결정적인 차이가 있는데요.

// 어떤 버튼을 찾을지 계획을 세웁니다.
const button: Locator = page.getByRole('button', { name: '구매하기' });

// 버튼을 찾고, 없으면 기다리고, 있으면 클릭합니다
await button.click();

예를 들어 위처럼 locator 코드만 덩그러니 써놓으면, 화면에 구매하기 버튼이 없더라도 테스트가 실패하지 않습니다. 화면에서 구매하기 버튼을 찾지 않기 때문입니다. locator 자체는 계획일 뿐입니다. promise도 아니고 평범한 객체지요.

이 locator로 click이나 fill, waitFor 같은 action을 할 때 비로소 요소를 찾고, 평가(evaluate)하게 됩니다.

click은 말 그대로 클릭이고요. fill은 값을 입력하는 겁니다. 지울 때에는 clear를 쓰고요. waitFor은 화면에 이 요소가 나타나기를 기다릴 때 씁니다. 이 기다리는 동작이 독특하니 더 자세히 설명해보지요.

자주 하는 실수 : role이 없거나 중첩하기

예를 들어 목록의 아이템을 링크로 만드는 경우, listitem 안에 link를 넣어줘야 합니다.

<h2 id='arti-list-title'>Arti with fromm store</h2>

<ul aria-labelledby='arti-list-title'>
    <li>
        <a href='/arti/leechaeyeon'> 이채연 </a>
    </li>
    <li>
        <a href='/arti/kanghyewon'> 강혜원 </a>
    </li>
</ul>

// 또는 
<div role='list' aria-label='Arti with fromm store'>
    <div role='listitem'>
        <Link href='/arti/leechaeyeon'> 이채연 </Link>
    </div>
    <div role='listitem'>
        <Link href='/arti/kanghyewon'> 강혜원 </Link>
    </div>
</div>

그러면 test에서도 link를 쉽게 찾을 수 있습니다.

await page.getByRole('list', { name: 'Arti' }).getByRole('link', { name: '강혜원' }).click();

그런데 element를 두 겹으로 감싸는 게 귀찮아서 하나로 합치면, role이 덮어 쓰여집니다!

<div role='list'>
    {/* link role이 listitem role로 덮어 씌워집니다! */}
    <Link role='listitem' href='/arti/leechaeyeon'> 이채연 </Link>
    <Link role='listitem' href='/arti/kanghyewon'> 강혜원 </Link>
</div>

당연히 테스트에서는 link role을 찾지 못해서 에러가 나고 삽질을 하게 됩니다. 하나의 element에 여러 개의 role을 달 수는 없습니다. 위의 li 안에 a 태그를 넣는 게 자연스러운 것처럼, 무의미한 div가 추가되는 것이 아니니 꼭, listitem과 link 혹은 button 등은 별개로 관리합시다.

자주 하는 실수 2 : textContent와 accessible name을 착각하기

button이나 link 등 상호작용이 가능한 요소들은 textContent를 accessible name으로 가지는 경우가 많습니다.

하지만 alert나 list, listitem 등은 name으로 찾으려 하면 찾지 못했다고 에러가 납니다. textContent가 있어도 name으로 여겨지지 않기 때문입니다.

<h2 id='arti-list-title'>Arti with fromm store</h2>

<ul aria-labelledby='arti-list-title'>
    <li>
        <a href='/arti/leechaeyeon'> 이채연 </a>
    </li>
    <li>
        <a href='/arti/kanghyewon'> 강혜원 </a>
    </li>
</ul>

// 성공! link는 textContent를 name으로 가집니다.
await page.getByRole('list', { name: 'Arti' }).getByRole('link', { name: '이채연' }).click();
// 에러! 이채연이라는 이름을 가진 listitem이 없습니다.
await page.getByRole('list', { name: 'Arti' }).getByRole('listitem', { name: '이채연' }).click();

그래서 되도록 link나 button 같은 상호작용 가능한 role을 잘 활용하시고, alert나 listitem은 명시적으로 aria-label, aria-labelledby를 달아주시거나, filter({ hasText: string })를 이용 하실 수도 있습니다.

<div role='alert'>{message}</div>

// 실패! name으로는 찾을 수 없습니다.
await expect(page.getByRole('alert', { name: '인증번호가 맞지 않습니다.' })).toBeVisible();
// 성공!
await expect(page.getByRole('alert').filter({ hasText: '인증번호가 맞지 않습니다.' })).toBeVisible();

로딩과 기다리기

playwright의 action이나 expect와 같은 assertion들을 보면 다들 await이 붙어 있습니다. 비동기인 건 알겠는데, 외부의 무엇을 기다리길래 비동기일까요?

api에서 데이터를 받거나, 이벤트에 의해 상태와 UI가 변경되는 데에는 시간이 걸립니다. 그 시간은 네트워크 사정에 따라 매우 오래 걸릴 수도 있고, 금방 끝날 수도 있습니다.

// Then "로그인" [alertdialog]로 물어본다
const alertDialog = page.getByRole('alertdialog', { name: '로그인' });
// When "확인"[button]을 클릭하면
await alertDialog.getByRole('button', { name: '확인' }).click();

// Then "로그인 페이지"로 이동한다
const form = page.getByRole('form', { name: '로그인' });
// 폼이 보일 때까지 기다립니다
await form.waitFor();

예를 들어 위에서 저희는 경고창에서 확인 버튼을 누르면 로그인 페이지로 이동한다고 했습니다.

안타깝게도 구매하기 버튼을 클릭하자마자 바로 경고창이 뜨는 건 아닙니다. 경고창이 뜰 때에는 에니메이션으로 서서히 나타나고요. 확인 버튼을 눌러도 로그인 페이지로 이동하는 데에는 시간이 걸릴 겁니다. 만약에 로그인 페이지로 아직 이동하기 전에 playwright가 “뭐야 버튼을 눌렀는데 아무 일도 안 일어나는데? 실패야 실패!” 하고 깨져버리면 안 될 것입니다.

다행히도 playwright는 당장 클릭할 대상이 보이지 않아도 자동으로 기다립니다. 화면에 보이더라도 애니메이션이 끝날 때까지 기다리고요. 화면에 보이더라도 disable 되지 않고 상호작용이 가능해질 때까지 기다리면서 재시도를 합니다. 그러니 await을 절대 빼먹어서는 안 되겠습니다.

그래서 timeout도 있습니다. 기본은 5000ms 즉 5초인데요. 우리 사이트가 너무 느려서 사용자도 5초 이상 기다릴게 확실하다면… timeout을 명시적으로 늘려줘야 할 것입니다.

자주하는 실수 3 : waitForTimeout으로 기다리기

Don’t use manual assertions that are not awaiting the expect.

베스트 프랙티스 문서에서도 말하지만, 자동으로 재시도를 하고 기다려주는 웹 우선의 assertion을 사용하셔야 합니다.

재시도를 하지 않는 일반 assertion 들을 사용하면 동기적으로 한 번 검사하고 바로 실패해버리기 때문이죠.

이렇게 테스트가 실패하면 인터넷에서 잘못된 조언을 보고 waitForTimeout 같은 고정된 시간으로 test를 돌리고는 하는데요. 이런 임시 방편이 당장은 편리하게 테스트를 통과시켜주는듯 보이지만, 실제로는 더 번거롭고 느리고 변덕스러운(flaky) 테스트로 이어지는 경우가 더 많습니다.

예를 들어 다음은 실제로 저희 팀에서 작성했던 잘못된 테스트의 예입니다. 화면을 스크롤하면 추가로 상품이 불러와지는지 테스트한 코드인데요.

test('스크롤을 내리면 상품이 추가적으로 노출된다.', async ({ page }) => {
    await setupAutoMockCache(page);
    await page.goto(`${CLIENT_HOST}${PathName}`);
    // page가 3초 안에 로딩되지 않는다면?
    await page.waitForTimeout(3000);

    // toHaveLength는 promise를 반환하지 않기 때문에 await을 붙여도 재시도를 하지 않습니다
    await expect(await page.getByRole('listitem').all()).toHaveLength(12);

    // 마지막 아이템으로 스크롤
    await page.getByRole('listitem').last().scrollIntoViewIfNeeded();
    // 새 데이터가 순식간에 도착하더라도 3초를 기다려서 느려집니다.
    await page.waitForTimeout(3000);

    // 3초 뒤에 아이템이 아직 12개라면 바로 테스트가 실패합니다.
    await expect(await page.getByRole('listitem').all()).toHaveLength(16);
});

얼마나 기다려야하는지 정확하게 아는 경우가 아니라면, waitForTimeout은 대부분 안 좋은 선택입니다. 실제로 실험하면서 정확한 시간을 찾아야 하고요. 너무 늦게 오면 테스트가 우연히 실패합니다. 그렇다고 시간을 넉넉히 잡아놓으면 데이터가 일찍 도착해도 너무 많은 시간을 기다리게 되어 테스트가 느려집니다.

이런 경우에는 toHaveLength 대신 web first assertion인 toHaveCount를 쓰면 됩니다. 해당하는 locator를 재시도하면서, 원하는 개수가 될 때까지 기다립니다. 별다른 로딩 처리를 하지 않아도 되서 코드도 간결해지고, 네트워크 속도에 상관 없이 안정적으로 테스트가 가능해집니다.

test('스크롤을 내리면 상품이 추가적으로 노출된다.', async ({ page }) => {
    await setupAutoMockCache(page);
    await page.goto(`${CLIENT_HOST}${PathName}`);

    await expect(page.getByRole('listitem')).toHaveCount(12);

    // 마지막 아이템으로 스크롤
    await page.getByRole('listitem').last().scrollIntoViewIfNeeded();

    await expect(page.getByRole('listitem')).toHaveCount(16);
});

앞으로 waitForTimeout을 써야하나 싶을 때 이렇게 자동으로 재시도하는 assertion을 찾아보시면, 대부분 더 나은 답을 찾으실 수 있을 겁니다.

외부 상태 의존성 재현하기

위에서 본 것과 같은 단순한 케이스들만 있다면 e2e 테스트는 그리 어렵지 않을 겁니다. 이상한 모킹이나 세팅도 필요 없겠죠.

하지만 안타깝게도 세상은 변합니다. 변하는 외부상태에 의존하게 되면 테스트는 쉽게 깨집니다. 예를 들어 위에서는 275번 상품을 구매하려 했는데요. 만약에 시간이 지나서 275번 상품이 판매를 종료하거나 품절되면 이 테스트는 실패하게 될 것입니다. 마찬가지로 test@wonderawll.kr이라는 테스트 계정이 없거나, 탈퇴했다면 마찬가지로 테스트가 불가능하겠죠.

이는 그럴지도 모른다는 예외가 아니라, 실제로 e2e를 유지보수하는 팀이라면 누구나 겪는 일입니다.

프롬에는 production과 거의 동일한 테스트용 dev 환경이 있습니다. 테스트를 위한 상품 데이터 등을 미리 셋업해두는데, 관계자들 사이에 협의만 잘 되면 테스트용으로 다양한 조건을 가진 데이터들을 쌓아둘 수 있습니다. 예를 들자면 2099년에 판매를 시작하는 상품이나, 절대 품절되지 않는 상품 등이 있겠습니다.

이렇듯 외부 상태를 직접 컨트롤할 수 있다면, 동일하게 맞춰두면 좋습니다. 실제 api와 의존성에 의지하는만큼, 테스트에서 성공했는데 프로덕션에서 깨지는 경우가 많이 줄어듭니다. 거꾸로 dev와 production의 미묘한 차이만 프로덕션에서 수동 테스트를 집중할 수 있죠.

이 문제에는 다양한 경우의 수가 있으니 다른 해결책을 더 찾아보겠습니다.

통제할 수 있는 부수효과를 직접 정리하기

사용자가 직접 삭제하거나 되돌릴 수 있는 부수효과라면, 생성하고 삭제하는 걸 하나의 테스트로 만들면 좋습니다.

예를 들어 장바구니에 상품을 담고, 삭제하는 동작과, 장바구니에 상품이 담긴 상태와, 비어 있는 상태를 테스트하고 싶다고 합시다. 대충 생각하면 케이스가 4개는 될 것 같습니다. 하지만 귀찮은 것이 장바구니의 상태가 어떤지 모른다는 것입니다. 장바구니에 이미 상품이 담겨 있을 수도 있고, 안 담겨 있을 수도 있습니다. 그러면 장바구니를 담는 테스트 전에는 장바구니가 비어 있게 셋업해줘야 하고, 삭제하기 전에는 장바구니에 상품이 이미 담겨 있게 셋업해줘야 하겠지요. mocking을 하더라도 여러모로 번거로울 겁니다.

더 쉬운 방법이 있습니다. 이 전체를 하나의 시나리오로 테스트하는 겁니다.

Given 로그인한 채로
Given 상품 페이지에서
When 장바구니에 담고
Then 장바구니로 이동할지 물으면
When 장바구니로 이동하고
When 전체 상품을 삭제하면
Then 삭제되었습니다라고 뜨고
Then '장바구니에 담긴 상품이 없습니다'가 보인다
When 상품 보러 가기 를 클릭하면
Then 상품 목록으로 이동한다

test('장바구니 시나리오', async ({ page }) => {
    // 실제 api
    await setupLogin(page);

    // 상품 페이지에서 장바구니에 상품 담기
    await page.goto(`${CLIENT_HOST}/goods/220`);
    await page.getByRole('button', { name: '장바구니' }).click();
    await page.getByRole('alertdialog', { name: '상품을 담았습니다.' }).getByRole('button', { name: '이동하기' }).click();

    // 상품이 담긴 상태로 장바구니 진입시 전체 선택이 활성화 되어있음
    await expect(page.getByRole('checkbox', { name: '전체' })).toBeChecked();

    // 선택된 전체 상품 삭제
    await page.getByRole('button', { name: '상품삭제' }).click();

    const alertDialog = page.getByRole('alertdialog', { name: '상품을 삭제' });
    await alertDialog.getByRole('button', { name: '확인' }).click();

    await page.getByRole('alert').filter({ hasText: '삭제되었습니다' }).waitFor();

    // 장바구니가 비어있음
    await expect(page.getByText('장바구니에 담긴 상품이 없습니다')).toBeVisible();

    await page.getByRole('link', { name: '상품 보러 가기' }).click();
});

외부 상태에 대해 가정을 적게 하면 더 유연한 테스트를 짤 수 있습니다. 예를 들어 이 테스트는 이미 장바구니에 물건이 담겨 있든, 비어 있든 통과합니다. 왜냐하면 장바구니가 비어 있을 때에도 상품을 하나 담고, 이미 장바구니에 하나가 담겨 있어도 추가로 하나 더 담은 뒤에 전체 삭제를 하기 때문입니다. 그리고 장바구니에 몇 개가 담겨 있었더라도 전체 삭제를 하면 장바구니는 비어 있게 됩니다. 심지어 장바구니를 전체 삭제하는데 실패하더라도, 다시 테스트를 돌리기 전에 수동으로 정리해주거나할 필요도 없죠.

그리고 인위적으로 케이스별로 분리한 테스트와 달리 이렇게 시나리오로 만든 테스트는, 페이지 간에 이동을 비롯해서 여러 복잡한 상태들을 짧고 간결하게 한 번에 테스트하게 해줍니다. 앞서 말씀 드린 것처럼 E2E는 통합 테스트보다 더 통합적으로 전 구간의 상호작용을 테스트합니다. 괜히 테스트를 쪼개서 느리고 복잡한 케이스를 만들기보다, 좀 길어지더라도 하나의 사용자 여정, 시나리오를 테스트하시면 외부 상태에 덜 의존하면서도 치밀한 테스트가 될 겁니다.

로그인, 설정 등의 유저 상태를 셋업하기

또 귀찮은 경우는 인증(Authentication)입니다. 로그인한 상태이거나, 권한이 있는 사용자(예를 들어 영상 콘텐츠를 구매한 사용자)만 이용할 수 있는 기능이 있다고 합시다. 이를 수동으로 테스트하려면 로그인했다가 로그아웃했다가를 반복해야겠죠. 앞에서 했던 것처럼 직접 아이디와 비밀번호를 입력해서 로그인할 수도 있습니다만. 더 간단한 방법도 여럿 있습니다.

만약에 인증 토큰을 cookie나 localStorage에 저장한다면, playwright는 스토리지 상태를 파일로 저장했다가 복원해주는 기능을 제공합니다. REST api 등으로 인증을 할 수 있으면, api를 이용해서 로그인을 한 토큰을 이용할 수도 있습니다. 이런 기능은 보통 자동 로그인을 구현할 때 사용하는 기술을 이용하면 쉽습니다. 물론 귀찮은 경우가 더 있긴 합니다. 2FA나 캡챠처럼 실제 사용자의 인증이 필요한 경우가 그런데요. 이런 경우에도 수동으로 인증 과정을 마치면 보통 쿠키나 토큰을 발급 받으니, 그러한 결과를 저장해놓고 사용하면 됩니다.

다양한 권한이나 상태를 가진 사용자를 여럿 만들어놓고, 테스트할 때 간단한 key 등으로 바꿔서 설정할 수 있게 만드시면 좋습니다. 기획서를 읽으면서 어떤 사용자 조건들이 필요한지 미리 정리해서 기획, 디자이너, 테스터 직군의 분들과 합의해두시면 편리할 겁니다. test에서는 기획서 등에 나오는 도메인의 개념을 이용하면 좋고, 테스트 데이터에 한해서는 한글 변수명을 사용해보는 것도 고려해볼만합니다. 예를 들어 저희 팀에서는 setupLogin이라는 셋업 함수를 만들어서 쓰고 있는데. 다음과 같이 테스트가 가능합니다.

const 베프친_구독_중이지_않은_친구 = 'test-1@wonderwall.kr';
test('베프친 구독 중이지 않은 친구가, 베프친 상품을 구매하려하면, 주문서로 넘어간다', async ({ page }) => {
    await setupLogin(page, 베프친_구독_중이지_않은_친구);

    // 구매 프로세스...
});

const 베프친_구독_중인_친구 = 'test-2@wonderwall.kr';
test('베프친 구독 중인 친구가, 베프친 상품을 구매하려하면, 이용권 재발급 경고창을 보여준다', async ({ page }) => {
    await setupLogin(page, 베프친_구독_중인_친구);

    // 구매 프로세스...
});

통제할 수 없는 부수효과 mocking하기

반면에 우리가 통제할 수 없는 부수효과도 있습니다. 보통 결제나 이메일 등이 그런데요. 이런 부수효과는 어쩔 수 없이 mocking을 하고, 나중에 수동 테스트해보는 경우가 많습니다. 실제로 kakaopay 결제 프로세스를 모두 거치게 자동화한다고 해도, kakao pay 결제 과정이 바뀌면 테스트를 다시 만들어야 하고요. 이메일 역시 네이버 메일, gmail로 시작해서 알림이 오는 등 다양하고 복잡한 시나리오를 아직 자동화하기 어렵기 때문입니다.

하지만 e2e 테스트에서 api mocking은 최후의 수단이 될 때가 많습니다. 왜냐하면 딱 하나라도 mocking을 하는 순간, 이를 전제로 하는 이후의 상호작용이 모두 망가지기 때문입니다.

예를 들어 저희의 프롬 서비스에서는 회원가입을 할 때 프롬 통합 ID인 email에 점유 확인을 하고 가입을 하는데요.

1. email로 인증 코드를 보내고
2. 사용자가 인증 코드를 입력하면 서버로 보내 검증하고
3. 나머지 정보를 입력한 뒤에 회원가입 요청을 보내고
4. 가입된 계정으로 자동 로그인을 시켜준다

는 흐름입니다. 만약에 email을 보내는 걸 mocking한다면 이 전 과정을 mocking 해야할 것입니다. 실제로 mocking하는 코드는 다음과 같이 생겼습니다. simpleMockApi는 playwright의 page.route 를 저희 팀의 api 응답 형식에 맞추면서, 보일러플레이트를 감싼 유틸 함수입니다.

async function mockSignupEmailCert(page: Page) {
    await simpleMockApi(page, '/auth/email', MockEmail);

    await page.route(`${API_HOST}/auth/email/verify`, async (route, request) => {
        const data = await request.postDataJSON();
        if (data.code === '181029') {
            return route.fulfill({ status: 200, json: { code: 200 } });
        } else {
            return route.fulfill({ status: 200, json: { code: 400 } });
        }
    });

    const me = { id: '497f6eca-6276-4993-bfeb-53cbbbba6f08', created: 1681648843454, email: 'user@example.com' };

    await simpleMockApi(page, '/auth/signUp', { token: MockToken, me });
}

잘못된 인증번호를 입력하면 실패하게 하는 로직도 만들어야 하니 공수가 꽤 큽니다. MSW나 nock 같은 다른 솔루션을 쓰더라도 백엔드를 간단하게나마 다시 만드는 것처럼 되고, 실제 백엔드 api와 동작이 100% 일치한다는 보장도 없습니다. 실제로 백엔드에서 잘못된 포맷으로 값을 보냈거나, 거꾸로 프런트에서 잘못 백엔드에 요청을 보낸 경우 테스트는 통과하지만 프로덕션에서 실패하게 됩니다. mocking을 하면 실패해야하는데 성공하는 걸로 착각하거나, 성공해야 하는데 실패하는 걸로 착각하는 경우가 많아서 여러모로 귀찮아지는 경우가 많습니다.

그럼에도 여전히 안타까운 점은 이메일이나 결제 등의 부수효과는 실제 환경에서 수동으로 테스트하기도 귀찮다는 것입니다. 결제를 테스트하려면 사용자에게 입력을 요구하는 값을 다 입력해봐야 하고요. 이메일도 이메일을 열어서 직접 확인해봐야 하고, 알림 등을 테스트하려면 모바일에서 개발 서버에 접속해야 하는데, 그러면 배포를 하거나, ngrok 등을 이용해서 localhost를 밖에서도 접속할 수 있게 프록시로 열어줘야 하는데요. CORS나 보안 등의 이슈까지 생각하면 더 번거로워지고는 합니다.

이런 경우도 실제 의존성과 유사한 환경을 구축할 수는 있습니다. 이메일은 mailhog 등의 메일 서버를 쓰는 경우도 있고, https://www.1secmail.com처럼 무료로 제공되는 임시 이메일 서비스도 있습니다. 결제 역시 테스트 환경에서 결제는 2FA 인증 등을 요구하지 않는다면 자동화할 수 있는 경우도 있습니다.

하지만 이 역시 외부에서 셋업하고 관리하기는 더 복잡해지며, 가짜 이메일 서비스와 실제 gmail이나 naver mail의 동작이 같다는 보장도 없습니다. mocking이나 자동화를 하기에 앞서 한 번 더 생각하고, 어디까지 할지, 수동 테스트는 어떨지 늘 신중하게 생각해보시길 권해드립니다.

e2e는 얼마나?

과학기술학자 홍성욱 교수 님이 쓰신 “과학은 얼마나?” 라는 책이 있습니다. 과학은 합리적인가? 아니면 사회적으로 짜고치는 구성된 결과물인가? 같은 이분법적인 질문이 아니라. 과학은 얼마나 합리적인지? 얼마나 믿을 수 있는지 고민해보자는 제목이었죠.

테스트도 비슷합니다. 세상에 테스트를 혐오하는 분들도 많습니다만, 테스트를 잘 하고 싶어하는 분들도 많습니다. 자동화 테스트든 수동 테스트든 안 할 수는 없습니다. 하긴 해야 하죠. 문제는 무엇을, 어떻게, 얼마나 테스트 할지입니다. 저는 제가 고민하고 생각하는 과정을 일부 보여드렸습니다만. 앞으로 생각해보실 문제들이 많습니다.

저는 실용주의자입니다. 자동화 테스트 100% 커버리지를 만들어본 사람은 그래도 에러가 난다는 걸 압니다. 세상에 방법은 많고 서로 상호 보완적입니다. 테스트하기 좋은 구조가 좋은 구조라고도 합니다만, 모든 레거시를 테스트하기 쉽게 만들 수 있는 것도 아닙니다. 저희도 타입스크립트를 쓰고 있지만 타입에도 뒤통수를 맞기도 합니다. 세상에는 타입으로 처리하면 더 쉬워지는 코드도 있습니다만. 회사에서 “이제 다 같이 ts-effect나 rescript로 강타입 함수형을 합시다~“하면 도입하게 되는 것도 아닙니다.

e2e 테스트는 강력합니다. 사용자와 유사하게, 직관적으로 테스트를 작성할 수 있고요. 코드리뷰를 통과한 에러들을 가장 많이 잡아내기도 합니다. 그 길이 항상 쉽진 않고요. playwright 문서만 조금씩 꾸준히 읽어보셔도 다양한 문제가 이미 해결되었다는 걸 깨닫게 되고, e2e가 치명적인 실수를 막아주는 경험도 여러 번 하시게될 겁니다.

하지만 e2e는 느리며, mocking을 하려할 수록 수렁에 빠지기 쉽습니다. 케이스가 복잡하다면 component나 unit test를 통해서 믿을 수 있게 만들고, E2E에서는 큰 흐름이나 연결만 검사하는게 좋습니다.

테스트는 무조건 많이 짠다고 좋은 게 아닙니다. 테스트도 코드이기 때문에 변경사항이 생기면 관리를 해야 합니다. 불필요하게 많은 테스트는 결국 유지보수 부담으로 돌아오게 됩니다. 많은 사람들이 테스트가 귀찮기만 하고, 도움은 안 된다고 착각하게 되는 이유이기도 합니다.

앞으로도 다양한 대안들과 문제들을 소개해보려 합니다. frontend에서 unit이나 component test는 무엇을 얼마나 해야하는지? type이나 schema 검증, 로깅이나 스냅샷 테스트 같은 시각적 테스트는 어떻게 하면 좋을지? 저 역시 아직 정답을 모르지만, 계속 고민하고 있습니다. 다시 또 뵙죠.