E2E 테스트

E2E 테스트에선 브라우저를 사용할 수 있기 때문에 실제 애플리케이션에 가까운 테스트가 가능하다
- 브라우저 고유의 API를 사용하는 상황 또는 화면을 이동하며 테스트해야하는 상황에 잘맞음
E2E 테스트 프레임워크로 테스트할 때 다음 상황에 구분하지 않고 E2E 테스트라 한다.
- 브라우저 고유 기능과 연동된 UI 테스트
- 데이터베이스 및 하위 시스템과 연동된 E2E 테스트
E2E 테스트는 무엇을 테스트할지 목적을 명확히 세우는 것이 가장 중요함
E2E 테스트에서 DB 서버 또는 외부 저장소 서비스를 포함한 전체 구조에서 얼마나 실제와 유사한 상황을 재현할 것인지가 중요한 기준점이 됨
- 어떤 관점에서 어떤 선택을 내려야 할지 상황별로 파악해보자.

브라우저 고유 기능과 연동한 UI 테스트 (피처 테스트)

웹 애플리케이션은 브라우저 고유 기능을 사용함
특정 상황에선jsdom 에서 제데로된 테스트를 할 수 없다.
- 화면 간 이동
- 화면 크기를 측정해서 실행된는 로직
- CSS 미디어 쿼리를 사용한 반응형 처리
- 스크롤 위치에 따른 이벤트 발생
- 쿠키나 로컬 스토리지 등에 데이터 저장
Jest에서 목 객체를 만들어 테스트를 작성할 수도 있지만 상황에 따라 브라우저로 실제 상황과 유사하게 테스트하고 싶다면 UI테스트를 하자.
- UI 테스트는 브라우저 고유 기능으로 인터렉션할 수 있으면 충분
- API 서버나 다른 하위 시스템은 목 서버로 만들어 E2E 테스트 프레임워크에서 연동된 기능을 검증하면 됨
- 이것을 피처 테스트라고도 부름

데이터베이스 및 서브 시스템과 연동한 E2E 테스트

일반적으로 웹 애플리케이션은 DB 서버나 외부 시스템과 연동하여 다음과 같은 기능을 제공한다.
- DB 서버와 연동하여 데이터를 불러오거나 저장
- 외부 저장소 서비스와 연동하여 이미지 등을 업로드
- 레디스와 연동하여 세션 관리
이를 최대한 실제와 유사하게 재현해 검증하는 테스트를 E2E 테스트라 한다.
E2E 테스트 프레임워크는 UI 자동화 기능으로 실제 애플리케이션을 브라우저 너머에서 조작한다.
표현 계층, 응용 계층, 영속 계층을 연동하여 검증하므로 실제 상황과 유사성이 높은 테스트로 자리매김함
많은 시스템과 연동하기 때문에 실행 시간이 길고, 불안정하다 (연동한 시스템이 문제가 있으면 실패)

Doker Compose

docker-compose.e2e.yaml

도커 컴포즈로 여러 도커 컨테이너를 실행하며, 컨테이너 간 통신으로 시스템을 연동해 테스트
- UI를 조작하면 영속 계층에 의도한 내용이 저장되고, 그 내용이 화면에 반영되는지를 검증
E2E 테스트에 도커 컴포즈를 도입하면 테스트 환경을 실행하고 종료하는 것이 편리해짐
CI에서 하나의 작업으로 실행할 수 있기 때문에 개발 워크플로에 포함시켜 쉽게 자동화 가능

Playwright

마이크로소프트가 공개한 E2E 프레임워크
크로스 브라우징 지원
다양한 기능 제공
- 디버깅 테스트
- 리포터
- 트레이스 뷰어
- 테스트 코드 생성기

설치 및 설정

$ npm init playwright@latest

# 타입스크립트와 자바스크립트 중 타입스크립트를 선택
? Do you want to use Typescript or Javascript? - Typescript
# 테스트 파일을 저장할 폴더를 설정. e2e라는 이름의 폴더를 사용
? Where to put your end-to-end tests? - e2e
# 깃허브 액션의 워크플로를 추가할지 말지 선택. - NO
? Add a GitHub Actions workflow? (y/N) - false
# 플레이라이트 브라우저를 설치
? Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) - true

설치가 완료되면 package.json에 필요한 모듈이 추가되고, 설정 파일 양식과 샘플 테스트 코드가 생성됨

처음 시작하는 E2E Test

브라우저 자동화 테스트는 테스트마다 브라우저를 열어 지정된 URL로 접속하는것으로 시작됨
- page.goto 에 URL 지정
수동으로 브라우저를 조작하면서 애플리케이션 기능을 검증하는 것을 코드로 대체해 테스트를 자동화 가능

import { test, expect } from '@playwright/test';

test("has title", async ({ page }) => {
  await page.goto("https://playwright.dev/");

  // 페이지 제목에 "Playwright"가 포함됐는지 검증한다.
  await expect(page).toHaveTitle(/Playwright/);
});

test("get started link", async ({ page }) => {
  await page.goto("https://playwright.dev/");

  // "Get started"라는 접근 가능한 이름을 가진 링크를 취득하고, 링크를 클릭한다.
  await page.getByRole("link", { name: "Get started" }).click();

  // 페이지 URL에 "intro"가 포함됐는지 검증한다.
  await expect(page).toHaveURL(/.*intro/);
});

로케이터

플레이라이트의 핵심 API

현재 페이지에서 특정 요소를 가져온다.
1.27.0 버전에는 테스팅 라이브러리로부터 영향을 받은 접근성 기반 로케이터가 추가됨
- 플레이라이트도 접근성 기반 로케이터를 우선적으로 사용하는 것을 권장한다
테스팅 라이브러리와 다른 점은 대기 시간이 필요한지에 따라 findByRole 등을 구분해서 사용하지 않아도 된다.
- 인터렉션은 비동기 함수이기 때문에 await 로 인터렉션이 완료될 때까지 기다린 후 다음 인터렉션이 실행하는 방식으로 작동됨

await page.getByLabel("User Name").fill("John");
await page.getByLabel("Password").fill("secret-password");
await page.getByRole("button", { name: "Sign in" }).click()

단언문

단언문은 명시적으로 expect 를 import 해서 작성함
vscode 에디터에선 인수에 로케이터를 할당하면 해당 요소 검증에 알맞은 매처를 추천함
Jest와 마찬가지로 not 을 사용해 진릿값을 반전시킬 수 있다.
expect 인수에는 페이지를 할당할 수도 있음
- 페이지를 인수로 넘기면 에디터가 페이지 검증용 매처를 추천해줌

import { expect } from '@playwright/test';
test("Locator를 사용한 단언문 작성법", async ({ page }) => {
  // 특정 문자열을 가진 요소를 취득해서 화면에 보이는 상태인지 검증
  await expect(page.getByText("Welcome John!")).toBeVisible();
  // 체크박스를 취득해 체크됐는지 검증
  await expect(page.getByRole("checkbox")).toBeChecked();
  // not으로 진릿값 반전
  await expect(page.getByRole("heading")).not.toContainText("some text");
})

import { expect } from '@playwright/test';
test("페이지를 사용한 단언문 작성법", async ({ page }) => {
  // 페이지 URL에 "intro"가 포함됐는지 검증
  await expect(page).toHaveURL(/.*intro/);
  // 페이지 제목에 "Playwright"가 포함됐는지 검증
  await expect(page).toHaveTitle(/Playwright/);
})

테스트할 애플리케이션 개요

예제 repo

$ npm i
$ brew install mino/stable/mc // MinIO Client 설치
$ docker compose up -d // 도커 컴포즈로 여러 컨테이너 실행하기
$ sh create-image-bucket.sh // 도커 컴포즈로 실행한 MinIO 서버에 버킷을 생성
$ npm run prisma:migrate // DB를 마이그레이션해서 테스트용 초기 데이터 주입
$ npm run dev // next.js 개발서버 실행 (docker compose up -d를 실행 한후 해야함)

Next.js

모든 페이지를 서버 사이드 렌더링으로 렌더링하며 인증된 요청인지 검사한다.
만약 로그인하지 않은 상황이면 로그인 화면으로 리다이렉트 시킨다.
Next.js는 레디스 서버와 연동하여 세션으로부터 사용자 정보를 취득한다.

Prisma

관게형 데이터베이스는 PostgreSQL 사용
Next.js 서버는 객체 관계 매핑(object-relational mapping, ORM) 도구로 프리즈마를 사용
프리즈마는 타입스크립트 호환성이 좋아서 인기가 많다.
- ex: 이너 조인한 테이블의 응답을 타입 추론으로 획득 가능

S3 Client

외부 파일 저장소 서비스로 AWS S3를 사용
로컬 환경에선 실제 버킷을 사용하지 않고 AWS S3 API와 호환이 가능한 MinIO를 사용
- 로컬 환경에서 개발 및 테스트할 때 사용
- 기사의 메인 및 프로필 이미지를 저장하는 공간으로 활용됨

개발 환경에서 E2E 테스트 설정

개발환경에서 테스트 실행하려면 빌드된 Next.js를 실행해야함

$ npm run build && npm start

E2E 테스트를 실행하기 전 DB의 테스트 데이터를 초기화하자. (이후 테스트의 영향을 미치기 때문)

$ npm run prisma:reset

E2E 테스트 실행

초기 설정을 사용하면 헤드리스 모드로 E2E 테스트를 실행하기 때문에 브라우저는 나타나지 않음

$ npx playwright test
$ npx playwright test Login.spec.ts // 특정 테스트 파일만 테스트 실행

테스트 결과를 리포트로 생성하고 싶다면 npx playwright show-report 를 실행
- 생성된 리포트는 http://localhost:9223/ 에서 확인 가능

플레이라이트 검사 도구를 활용한 디버깅

E2E 테스트를 작성하다보면 기대한것과 다르게 테스트가 통과되지 않을 떄가 있음
이럴 땐 플레이라이트 검사 도구로 원인을 파악해야 한다.
테스트를 실행하는 커맨드에 --debug 옵션을 붙이면 headed 모드로 테스트가 시작됨
- 브라우저를 열어서 육안으로 자동화된 UI 테스트를 확인할 수 있는 모드
검사 도구를 사용하면 실행 중인 테스트 코드를 보면서 UI가 어떻게 조작되는지 확인 가능
좌측 상단에 녹색 삼각형 재생 아이콘을 클릭하면 UI 테스트 시작됨
재생 아이콘 우측에 녹색 화살표 형태의 스텝 오버 아이콘을 클릭하면 한 줄 씩 테스트 코드가 실행됨

$ npx playwright test Login.spec.ts --debug

도커 컴포즈를 사용하는 E2E 테스트

다른 테스트와 다르게 초기에 컨테이너를 빌드하는 시간이 필요
CI용으로 작성한 것

$ npm run docker:e2e:build && npm run docker:e2e:ci

로그인 기능 E2E 테스트

로그인 여부에 따라 애플리케이션이 기대한 대로 작동하는지 검증
이를 검증하려면 로그인한 후에 특정 작업을 수행하는 인터렉션을 자주 사용해야 한다.
로그인 상태와 연관된 기능 테스트를 위해 반복적인 작업을 공통화하는것이 중요

등록 완료된 사용자로 로그인하기

로그인하는 인터렉션을 함수로 만들어 공통화

// e2e/utils.ts
export async function login({
  page,
  userName = "JPub",
}: {
  page: Page;
  userName?: UserName;
}) {
  const user = getUser(userName);
  await page.getByRole("textbox", { name: "메일주소" }).fill(user.email);
  await page.getByRole("textbox", { name: "비밀번호" }).fill(user.password);
  await page.getByRole("button", { name: "로그인" }).click();
}

export function url(path: string) {
  return `http://localhost:3000${path}`;
}

로그인 상태에서 로그아웃

로그아웃 인터렉션도 동일하게 함수로 만들어 공통화

// e2e/utils.ts
export async function logout({
  page,
  userName = "JPub",
}: {
  page: Page;
  userName?: UserName;
}) {
  const user = getUser(userName);
  const loginUser = page.locator("[aria-label='로그인한 사용자']").getByText(user.name)
  await loginUser.hover(); // 마우스를 올려 로그아웃 버튼이 나타나게 함
  await page.getByText("로그아웃").click()
}

로그인 상태가 아니면 로그인 화면으로 리다이렉트 시키기

미로그인 사용자가 해당 페이지에 접근하면 로그인 화면으로 리다이렉트시켜서 로그인을 요청하는 플로우
이 작업도 대부분 테스트에서 필요한것이라 함수로 공통화
로그인 상태가 아니면 접근할 수 없는 페이지에는 assertUnauthorizedRedirect 함수로 미로그인 사용자가 리다이렉트 됐는지 검증

export async function assertUnauthorizedRedirect({
  page,
  path
}: {
  page: Page;
  path: string;
}) {
  // 지정된 페이지에 접근
  await page.goto(url(path));
  // 리다이렉트될 때까지 기다림
  await page.waitForURL(url("/login"));
  // 로그인 페이지로 이동했는지 확인
  await expect(page).toHaveTitle("로그인 | Tech Posts");
}

test("로그인 상태가 아니면 로그인화면으로 리다이렉트된다.", async ({ page }) => {
  const path = "/my/posts"; // 접근할 URL 경로
  await assertUnauthorizedredirect({ page, path })
})

로그인 후 리다이렉트 이전화면으로 돌아가기

예제 코드
로그인 후에 리다이렉트 전 페이지로 돌아가는지 검증

if (err instanceof UnauthroizedError) {
  session.redirectUrl = ctx.resolvedUrl;
  return { redirect: { permanent: false, destination: "/login" } };
}

test.describe("로그인 페이지", () => {
  const path = "/login";
  
  test("로그인 성공 시 리다이렉트 이전 페이지로 돌아간다", async ({ page }) => {
    await page.goto(url("/my/posts"));
    await expect(page).toHaveURL(url(path)); //로그인 화면으로 리다이렉트됨
    await login({ page }); // 로그인 인터렉션을 실행하는 유팉 함수
    await expect(page).toHaveURL(url("/my/posts"));
  })
})

프로필 기능 E2E 테스트

UI를 조작해서 프로필 갱신 API 요청을 발생시킴
API Routes가 작동하고 DB 서버에 값이 저장됨
세션에 저장된 값이 갱신됨
새로운 페이지 제목은 갱신된 세션값을 참조

getServerSideProps로 로그인한 사용자 정보 취득하기

서버 사이드 렌더링을 위한 데이터 취득 함수인 getServerSideProps 는 로그인 상태를 검사하는 고차함수(withLogin) 에 래핑되어있음
인수인 user에는 로그인한 사용자의 정보가 저장됐는데, 해당 로그인 정보를 기반으로 페이지의 데이터를 요청하거나 프로필 정보를 취득한다.
user 객체는 세션에 저장된 정보를 불러옴

Page.getPageTitle = PageTitle(
  ({ data }) => `${data?.authorName}님의 프로필 편집`
);

// 로그인 상태 확인을 포함한 getServerSideProps
export const getServerSideProps = withLogin<Props>(async ({ user }) => {
  return {
  // 프리즈마 클라이언트를 래핑한 함수를 통해 데이터베이스에서 데이터를 취득
    profile: await getMyProfileEdit({ id: user.id }),
    authorName: user.name // 제목에 사용할 유저명을 Props에 포함시킴
  }
})

프로필 정보를 갱신하는 API Routes

Next.js는 API Routes라는 웹 API 구현 기능을 제공함
UI를 조작해 비동기로 데이터를 취득하거나 갱신하는 요청을 받았을 때 서버 프로세스에서 작업을 처리하여 JSON 같은 형식으로 API 응답을 반환한다.
"대부분 코드가 프리즈마 의존성있는 코드라 일단 스킵"

import { expect, test } from '@playwright/test';
import { UserName } from '../prisma/fixtures/user';
import { login, url } from './util';

test.describe("프로필 편집 페이지", () => {
  const path = "/my/profile/edit";
  const userName: UserName = "User-MyProfileEdit";
  const newName = "NewName";
  
  test("프로필을 편집하면 프로필에 반영된다.", async ({ page }) => {
    await page.goto(url(path));
    await login({ page, userName });
    // 여서부터 프로필 편집 화면
    await expect(page).toHaveURL(url(path));
    await expect(page).toHaveTitle(`${userName}님의 프로필 편집`);
    await page.getByRole("textbox", { name: "사용자명" }).fill(newName);
    await page.getByRole("button", { name: "프로필 변경하기" }).click();
    await page.waitForURL(url("/my/posts"));
    // 페이지 제목에 방금 입력한 이름이 포함됨
    await expect(page).toHaveTitle(`${newName}님의 기사 목록`);
    await expect(page.getByRole("region", { name: 프로필" })).toContainText(newName);
    await expect(page.locator("[aria-label='로그인한 사용자']")).toContainText(newName);
    
  })
})

Like 기능 E2E 테스트

기획
- 로그인한 사용자만 Like를 누를 수 있다.
- 단, 자신이 작성한 기사에는 누를 수 없다.
검증
- 다른 사람이 작성한 기사에는 Like를 누를 수 있어야 한다.
- 자신의 기사에는 Like를 누를 수 없어야 한다.

다른 사람이 작성한 기사에는 Like 버튼을 누를 수 있어야 한다.

test("다른 사람의 기사에는 Like 할 수 있다.", async ({ page }) => {
  await page.goto(url("/login"));
  await login({ page, userName: "Jpub" });
  await expect(page).toHaveURL(url("/"));
  // 여기서부터 기사 목록 페이지
  await page.goto(url("/posts/10"));
  const buttonLike = page.getByRole("button", { name: "Like" });
  const buttonText = page.getByTestId("likeStatus");
  // like 버튼이 활성화되고, 현재 Like 수는 0
  await expect(buttonLike).toBeEnabled();
  await expect(buttonLike).toHaveText("0");
  await expect(buttonText).toHaveText("Like");
  await buttonLike.click();
  // like를 클릭하면 카운트가 1증가하고 이미 like 누른 상태가 된다.
  await expect(buttonLike).toHaveText("1");
  await expect(buttonText).toHaveText("Liked");
})

본인이 작성한 기사에는 like 버튼을 누를 수 없다.

test("본인이 작성한 기사에는 Like 할 수 없다.", async ({ page }) => {
  await page.goto(url("/login"));
  await login({ page, userName: "Jpub" });
  await expect(page).toHaveURL(url("/"));
  // 여기서부터 기사 목록 페이지
  await page.goto(url("/posts/90"));
  const buttonLike = page.getByRole("button", { name: "Like" });
  const buttonText = page.getByTestId("likeStatus");
  // like 버튼이 비활성화되고, Like 문자도 사라짐
  await expect(buttonLike).toBeDisabled();
  await expect(buttonText).not.toHavetext("Like");
})

신규 작성 페이지 E2E 테스트

이른바 CRUD라 불리는 기능의 페이지 테스트
CRUD 기능 테스트는 다른 테스트에 영향을 미치지 않는지 세심히 살펴봐야 한다.
기본적으로 Publish 기능 테스트는 새로운 기사를 작성한 후 해당 기사를 대상으로 CRUD해야 한다.

신규 작성 페이지에 접근해 컨텐츠를 입력하는 함수

투고 기능의 E2E 테스트에는 새 기사를 작성하는 작업을 여러 번 실행해야 한다.
컨텐츠 내용은 신경쓰지 말고 필수 입력 항목만 채우는 인터렉션 함수를 만든다.
다른 테스트에 영향을 미치지 않도록 재사용 가능한 기사 작성 함수를 만들어보자.

//e2e/postUtils.ts
export async function gotoAndFillPostContents({
  page,
  title,
  userName,
}: {
  page: Page;
  title: string;
  userName: UserName;
}) {
  await page.goto(url("/login"));
  await login({ page, userName });
  await expect(page).toHaveURL(url("/"));
  await page.goto(url("/my/posts/create"));
  await page.setInputFiles("data-testid=file", [
    "public/__mocks__/images/img01.jpg",
  ]);
  await page waitForLoadState("networkidle", { timeout: 30000 });
  await page.getbyRole("textbox", { name: "제목" }).fill(title);
}

신규 기사를 비공개 상태로 저장하는 함수

신규 기사를 비공개 상태로 저장하는 작업도 여러 번 실행되는 인터렉션

//e2e/postUtils.ts
export async function gotoAndCreatePostAsDraft({
  page,
  title,
  userName,
}: {
  page: Page;
  title: string;
  userName: UserName;
}) {
  await gotoAndFillPostContents({ page, title, userName });
  await page.getByRole("button", { name: "비공개 상태로 저장" }).click();
  await page.waitForNavigation();
  await expect(page).toHaveTitle(title);
}

신규 기사를 공개하는 함수

//e2e/postUtils.ts
export async function gotoAndCreatePostAsPublish({
  page,
  title,
  userName,
}: {
  page: Page;
  title: string;
  userName: UserName;
}) {
  await gotoAndFillPostContents({ page, title, userName });
  await page.getByText("공개 여부").click();
  await page.getByRole("button", { name: "공개하기" }).click();
  await page.getByRole("button", { name: "" }).click();
  await page.waitForNavigation();
  await expect(page).toHaveTitle(title);
}

재사용되는 유틸 함수들을 활용하여 E2E 테스트 작성하기

expect 함수를 사용하는 단언문도 앞서 만든 함수들에 포함됐으므로 검증이 간단해진다.

//e2e/MyPostscreate.spec.ts
import { test } from '@playwright/test';
import { UserName } from '../prisma/fixtures/user';
import {
  gotoAndCreatePostAsDraft,
  gotoAndCreatePostAsPublish
} from './postUtil';

test.describe("신규 기사 페이지", () => {
  const path = "/my/posts/create";
  const userName: UserName = "JPub";
  
  test("신규 기사를 비공개 상태로 저장할 수 있다.", async ({ page }) => {
    const title = "비공개 상태로 저장하기 테스트";
    await gotoAndCreatePostAsDraft({ page, title, userName });
  })
  
  test("신규 기사를 공개할 수 있다.", async ({ page }) => {
    const title = "공개하기 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
  })
})

기사 편집 페이지 E2E 테스트

기사를 편집했을 때 기사 목록에 미치는 영향과 기사를 삭제하는 기능에 대한 E2E 테스트

공통 함수

작성된 기사 페이지로 이동한 뒤 편집 페이지로 이동하는 인터렉션 함수

export async function gotoEditPostPage({
  page,
  title,
}: {
  page: Page;
  title: string;
}) {
  await page.getByRole("link", { name: "편집하기" }).click();
  await page.waitForNavigation();
  await expect(page).toHaveTitle(`기사 편집 | ${title}`);
}

검증

비공개 상태로 저장한 기사를 편집해 내용이 갱신되는지 검증
비공개 상태로 저장한 기사 공개 상태로 변경할 수 있는지 검증
공개된 기사를 편집하고 비공개 상태로 변경할 수 있는지 검증
공개된 기사를 삭제할 수 있는지 검증

import { expect, test } from "@playwright/test";
import { checkA11y, injectAxe } from "axe-playwright";
import { UserName } from "../prisma/fixtures/user";
import {
  gotoAndCreatePostAsDraft,
  gotoAndCreatePostAsPublish,
  gotoEditPostPage,
} from "./postUtil";
import { assertUnauthorizedRedirect, url } from "./util";

test.describe("기사 편집 페이지", () => {
  const path = "/my/posts/1/edit";
  const userName: UserName = "JPub";

  test("로그인 상태가 아니면 로그인 화면으로 리다이렉트된다", async ({ page }) => {
    await assertUnauthorizedRedirect({ page, path });
  });

  test("비공개 기사를 편집할 수 있다", async ({ page }) => {
    const title = "비공개 편집 테스트";
    const newTitle = "비공개 편집 테스트 갱신 완료";
    await gotoAndCreatePostAsDraft({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByRole("textbox", { name: "제목" }).fill(newTitle);
    await page.getByRole("button", { name: "비공개 상태로 저장" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(newTitle);
  });

  test("비공개 기사를 공개할 수 있다", async ({ page }) => {
    const title = "비공개 기사 공개 테스트";
    await gotoAndCreatePostAsDraft({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByText("공개 여부").click();
    await page.getByRole("button", { name: "공개하기" }).click();
    await page.getByRole("button", { name: "네" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(title);
  });

  test("공개된 기사를 비공개할 수 있다", async ({ page }) => {
    const title = "기사 비공개 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByText("공개 여부").click();
    await page.getByRole("button", { name: "비공개 상태로 저장" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(title);
  });

  test("공개된 기사를 삭제할 수 있다", async ({ page }) => {
    const title = "기사 삭제 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByRole("button", { name: "삭제하기" }).click();
    await page.getByRole("button", { name: "네" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(`${userName}님의 기사 목록`);
  });

  test("접근성 검증", async ({ page }) => {
    await page.goto(url(path));
    await injectAxe(page as any);
    await checkA11y(page as any);
  });
});

기사 목록 페이지 E2E 테스트

신규 기사가 작성되면 기사 목록에 어떤 영향을 미치는지에 대한 E2E 테스트
기사 목록은 메인 페이지와 마이 페이지 두 곳에 존재
- 비공개 상태로 저장한 기사는 작성자 외 열람이 불가능하므로 메인 페이지에선 노출되지 않아야함

검증

마이 페이지의 기사 목록에 신규 기사가 추가됐는지 검증
- 비공개 상태로 저장한 기사와 공개 상태로 저장한 기사 모두 목록에 추가돼야함
메인 페이지의 기사 목록에 신규 기사가 추가됐는지 검증
- 비공개 상태로 저장한 기사는 목록에 안보여야함

import { expect, test } from "@playwright/test";
import { checkA11y, injectAxe } from "axe-playwright";
import { UserName } from "../prisma/fixtures/user";
import {
  gotoAndCreatePostAsDraft,
  gotoAndCreatePostAsPublish,
} from "./postUtil";
import { assertUnauthorizedRedirect, login, url } from "./util";

/* 코드 10-15
test("로그인 상태가 아니면 로그인 화면으로 리다이렉트된다", async ({ page }) => {
  const path = "/my/posts";
  await assertUnauthorizedRedirect({ page, path });
});
*/

test.describe("게재된 기사 목록 페이지", () => {
  const path = "/my/posts";
  const userName: UserName = "JPub";

  test("로그인 상태가 아니면 로그인 화면으로 리다이렉트된다", async ({ page }) => {
    await assertUnauthorizedRedirect({ page, path });
  });

  test("자신의 프로필을 열람할 수 있다", async ({ page }) => {
    await page.goto(url(path));
    await login({ page });
    await expect(page).toHaveURL(url(path));
    const profile = page.getByRole("region", { name: "프로필" });
    await expect(profile).toContainText("JPub");
  });

  test("신규 기사를 비공개 상태로 저장하면 게재된 기사 목록에 기사가 추가된다", async ({
    page,
  }) => {
    const title = "비공개로 저장된 기사 목록 테스트";
    await gotoAndCreatePostAsDraft({ page, title, userName });
    await page.goto(url(path));
    await expect(page.getByText(title)).toBeVisible();
  });

  test("신규 기사를 공개 상태로 저장하면 게재된 기사 목록에 기사가 추가된다", async ({
    page,
  }) => {
    const title = "공개 상태로 저장된 기사 목록 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
    await page.goto(url(path));
    await expect(page.getByText(title)).toBeVisible();
  });

  test("접근성 검증", async ({ page }) => {
    await page.goto(url(path));
    await injectAxe(page as any);
    await checkA11y(page as any);
  });
});

불안정한 테스트 대처 방법

흔히 E2E 테스트는 안정적이지 않다고 생각함
- 불안정한 테스트는 네트워크 지연이나, 메모리 부족에 의한 서버 응답 지연 등 다양한 원인으로 발생함
- 테스트 실행 순서의 영향으로 의도하지 않은 상태에서 테스트를 시작하여 문제가 발생하기도 함
이런 다양한 원인으로 불안정한 테스트가 발생하는 것은 E2E 테스트에선 피할 수 없는 문제
- 몇가지 대처 방법은 존재한다.

실행할 때마다 데이터베이스 재설정하기

DB를 사용하는 E2E 테스트는 테스트를 실행하면 데이터가 변경된다.
일관성있는 결과를 얻으려면 테스트 시작 시점의 상태는 항상 동일해야 한다.
- 테스트를 실행할 때마다 시드 스크립트로 초깃값을 재설정 해야함?

테스트마다 사용자를 새로 만들기

프로필 편집 기능을 테스트한다고 기존 사용자 정보를 변경하면 안됨
테스트에선 각 테스트를 위해 생성한 사용자를 사용해야 한다.
테스트가 끝나면 테스트용 사용자는 제거

테스트 간 리소스가 경합하지 않도록 주의

CRUD 기능의 E2E 테스트처럼 각 테스트에서 매번 새로운 리소스를 작성하도록 해야함
플레이라이트 테스트는 병렬처리되기 때문에 테스트 실행 순서를 보장할 수 없다.
불안정한 테스트가 발견되면 리소스 경합이 발생하고 있는지 검토해야함

리소스 경합이란?

여러 프로세스나 스레드가 동시에 동일한 자원(예: CPU, 메모리, 디스크, 네트워크 등)에 접근하려고 할 때 발생하는 문제를 말한다

빌드한 애플리케이션 서버로 테스트하기

next.js 애플리케이션에서 개발할 때는 개발 서버에서 디버깅하며 코드를 작성하지만 E2E 테스트는 개발 서버에서 실행하지 않도록 주의해야 한다.
빌드한 Next.js 애플리케이션은 개발 서버와 다르게 동작하기 때문
또한 개발 서버는 응답 속도도 느려서 불안정한 테스트의 원인이 되기도함

비동기 처리 대기하기

예를들어 이미지 업로드 인터렉션이 있다면, 네트워크 통신이 완료될 때까지 기다려야 한다.
이처럼 시간이 걸리는 작업은 단위 테스트에서 했던것처럼 비동기 처리 응답을 대기해야 한다.
만약 조작할 요소가 존재하고 문제없이 인터렉션이 할당됐음에도 테스트가 실패한다면 비동기 처리를 제데로 대기하는지 확인해야함

--debug로 테스트 실패 원인 조사하기

불안정한 테스트의 원인을 파악하려면 디버거를 활용해야함
플레이라이트는 실행할 때 --debug 를 붙이면 디버거를 실행할 수 있음
직접 디버거에서 한 줄 씩 작동을 확인하며 실패 원인을 파악해보자.

CI 환경과 CPU 코어 수 맞추기

로컬에서 테스트를 실행하는 경우 모두 통과하지만 CI 환경에서는 실패하기도 한다.
이 경우 로컬 기기의 CPU 코어 수와 CI 코어수가 동일한지 체크해야 한다.
플레이라이트나 제스트는 코어 수를 명시적으로 지정하지 않으면 실행 환경에서 실행 가능한 만큼 테스트 스위트를 병렬 처리한다.
- 즉, 병렬처리되는 숫자는 실행 환경의 CPU 코어 수 떄문에 변동됨
CPU 코어 수가 변도되지 않도록 고정하는 설정을 추가한다. (테스트 러너에 지정할 수 있음)
CI의 코어 수에 맞춰 설정한 후, 로컬에서도 모든 테스트가 통과되면 문제 해결
만약 해결되지 않은 경우 대기 시간의 상한을 늘려보자.
- 전체적으로 보면 CI에서 테스트가 실패해 계속 재시도 하는 것보다 시간을 단축시킬 수 있다.

테스트 범위 최소화

상황에 따라 E2E 테스트로 검증하는 것이 적절한지 살펴봐야 한다.
테스트 피라미드 상층부에 가까울 수록 실제 상황과 유사한 테스트가 가능하지만, 반대로 불안정성이 증가하고 실행시간도 길어짐
E2E 테스트를 더 넓은 범위의 통합 테스트로 대체가능하면 더 적은 비용으로 안정적인 테스트를 할 수 있다.
검증 내용에 맞는 최적의 테스트 범위를 찾아야 불안정한 테스트가 생길 가능성이 낮아진다.

Previous시각적 회귀 테스트 NextGithub Actions 설정

Last updated 10 months ago

E2E 테스트

E2E 테스트에선 브라우저를 사용할 수 있기 때문에 실제 애플리케이션에 가까운 테스트가 가능하다
- 브라우저 고유의 API를 사용하는 상황 또는 화면을 이동하며 테스트해야하는 상황에 잘맞음
E2E 테스트 프레임워크로 테스트할 때 다음 상황에 구분하지 않고 E2E 테스트라 한다.
- 브라우저 고유 기능과 연동된 UI 테스트
- 데이터베이스 및 하위 시스템과 연동된 E2E 테스트
E2E 테스트는 무엇을 테스트할지 목적을 명확히 세우는 것이 가장 중요함
E2E 테스트에서 DB 서버 또는 외부 저장소 서비스를 포함한 전체 구조에서 얼마나 실제와 유사한 상황을 재현할 것인지가 중요한 기준점이 됨
- 어떤 관점에서 어떤 선택을 내려야 할지 상황별로 파악해보자.

브라우저 고유 기능과 연동한 UI 테스트 (피처 테스트)

웹 애플리케이션은 브라우저 고유 기능을 사용함
특정 상황에선jsdom 에서 제데로된 테스트를 할 수 없다.
- 화면 간 이동
- 화면 크기를 측정해서 실행된는 로직
- CSS 미디어 쿼리를 사용한 반응형 처리
- 스크롤 위치에 따른 이벤트 발생
- 쿠키나 로컬 스토리지 등에 데이터 저장
Jest에서 목 객체를 만들어 테스트를 작성할 수도 있지만 상황에 따라 브라우저로 실제 상황과 유사하게 테스트하고 싶다면 UI테스트를 하자.
- UI 테스트는 브라우저 고유 기능으로 인터렉션할 수 있으면 충분
- API 서버나 다른 하위 시스템은 목 서버로 만들어 E2E 테스트 프레임워크에서 연동된 기능을 검증하면 됨
- 이것을 피처 테스트라고도 부름

데이터베이스 및 서브 시스템과 연동한 E2E 테스트

일반적으로 웹 애플리케이션은 DB 서버나 외부 시스템과 연동하여 다음과 같은 기능을 제공한다.
- DB 서버와 연동하여 데이터를 불러오거나 저장
- 외부 저장소 서비스와 연동하여 이미지 등을 업로드
- 레디스와 연동하여 세션 관리
이를 최대한 실제와 유사하게 재현해 검증하는 테스트를 E2E 테스트라 한다.
E2E 테스트 프레임워크는 UI 자동화 기능으로 실제 애플리케이션을 브라우저 너머에서 조작한다.
표현 계층, 응용 계층, 영속 계층을 연동하여 검증하므로 실제 상황과 유사성이 높은 테스트로 자리매김함
많은 시스템과 연동하기 때문에 실행 시간이 길고, 불안정하다 (연동한 시스템이 문제가 있으면 실패)

Doker Compose

docker-compose.e2e.yaml

도커 컴포즈로 여러 도커 컨테이너를 실행하며, 컨테이너 간 통신으로 시스템을 연동해 테스트
- UI를 조작하면 영속 계층에 의도한 내용이 저장되고, 그 내용이 화면에 반영되는지를 검증
E2E 테스트에 도커 컴포즈를 도입하면 테스트 환경을 실행하고 종료하는 것이 편리해짐
CI에서 하나의 작업으로 실행할 수 있기 때문에 개발 워크플로에 포함시켜 쉽게 자동화 가능

Playwright

마이크로소프트가 공개한 E2E 프레임워크
크로스 브라우징 지원
다양한 기능 제공
- 디버깅 테스트
- 리포터
- 트레이스 뷰어
- 테스트 코드 생성기

설치 및 설정

$ npm init playwright@latest

# 타입스크립트와 자바스크립트 중 타입스크립트를 선택
? Do you want to use Typescript or Javascript? - Typescript
# 테스트 파일을 저장할 폴더를 설정. e2e라는 이름의 폴더를 사용
? Where to put your end-to-end tests? - e2e
# 깃허브 액션의 워크플로를 추가할지 말지 선택. - NO
? Add a GitHub Actions workflow? (y/N) - false
# 플레이라이트 브라우저를 설치
? Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) - true

설치가 완료되면 package.json에 필요한 모듈이 추가되고, 설정 파일 양식과 샘플 테스트 코드가 생성됨

처음 시작하는 E2E Test

브라우저 자동화 테스트는 테스트마다 브라우저를 열어 지정된 URL로 접속하는것으로 시작됨
- page.goto 에 URL 지정
수동으로 브라우저를 조작하면서 애플리케이션 기능을 검증하는 것을 코드로 대체해 테스트를 자동화 가능

import { test, expect } from '@playwright/test';

test("has title", async ({ page }) => {
  await page.goto("https://playwright.dev/");

  // 페이지 제목에 "Playwright"가 포함됐는지 검증한다.
  await expect(page).toHaveTitle(/Playwright/);
});

test("get started link", async ({ page }) => {
  await page.goto("https://playwright.dev/");

  // "Get started"라는 접근 가능한 이름을 가진 링크를 취득하고, 링크를 클릭한다.
  await page.getByRole("link", { name: "Get started" }).click();

  // 페이지 URL에 "intro"가 포함됐는지 검증한다.
  await expect(page).toHaveURL(/.*intro/);
});

로케이터

플레이라이트의 핵심 API

현재 페이지에서 특정 요소를 가져온다.
1.27.0 버전에는 테스팅 라이브러리로부터 영향을 받은 접근성 기반 로케이터가 추가됨
- 플레이라이트도 접근성 기반 로케이터를 우선적으로 사용하는 것을 권장한다
테스팅 라이브러리와 다른 점은 대기 시간이 필요한지에 따라 findByRole 등을 구분해서 사용하지 않아도 된다.
- 인터렉션은 비동기 함수이기 때문에 await 로 인터렉션이 완료될 때까지 기다린 후 다음 인터렉션이 실행하는 방식으로 작동됨

await page.getByLabel("User Name").fill("John");
await page.getByLabel("Password").fill("secret-password");
await page.getByRole("button", { name: "Sign in" }).click()

단언문

단언문은 명시적으로 expect 를 import 해서 작성함
vscode 에디터에선 인수에 로케이터를 할당하면 해당 요소 검증에 알맞은 매처를 추천함
Jest와 마찬가지로 not 을 사용해 진릿값을 반전시킬 수 있다.
expect 인수에는 페이지를 할당할 수도 있음
- 페이지를 인수로 넘기면 에디터가 페이지 검증용 매처를 추천해줌

import { expect } from '@playwright/test';
test("Locator를 사용한 단언문 작성법", async ({ page }) => {
  // 특정 문자열을 가진 요소를 취득해서 화면에 보이는 상태인지 검증
  await expect(page.getByText("Welcome John!")).toBeVisible();
  // 체크박스를 취득해 체크됐는지 검증
  await expect(page.getByRole("checkbox")).toBeChecked();
  // not으로 진릿값 반전
  await expect(page.getByRole("heading")).not.toContainText("some text");
})

import { expect } from '@playwright/test';
test("페이지를 사용한 단언문 작성법", async ({ page }) => {
  // 페이지 URL에 "intro"가 포함됐는지 검증
  await expect(page).toHaveURL(/.*intro/);
  // 페이지 제목에 "Playwright"가 포함됐는지 검증
  await expect(page).toHaveTitle(/Playwright/);
})

테스트할 애플리케이션 개요

예제 repo

$ npm i
$ brew install mino/stable/mc // MinIO Client 설치
$ docker compose up -d // 도커 컴포즈로 여러 컨테이너 실행하기
$ sh create-image-bucket.sh // 도커 컴포즈로 실행한 MinIO 서버에 버킷을 생성
$ npm run prisma:migrate // DB를 마이그레이션해서 테스트용 초기 데이터 주입
$ npm run dev // next.js 개발서버 실행 (docker compose up -d를 실행 한후 해야함)

Next.js

모든 페이지를 서버 사이드 렌더링으로 렌더링하며 인증된 요청인지 검사한다.
만약 로그인하지 않은 상황이면 로그인 화면으로 리다이렉트 시킨다.
Next.js는 레디스 서버와 연동하여 세션으로부터 사용자 정보를 취득한다.

Prisma

관게형 데이터베이스는 PostgreSQL 사용
Next.js 서버는 객체 관계 매핑(object-relational mapping, ORM) 도구로 프리즈마를 사용
프리즈마는 타입스크립트 호환성이 좋아서 인기가 많다.
- ex: 이너 조인한 테이블의 응답을 타입 추론으로 획득 가능

S3 Client

외부 파일 저장소 서비스로 AWS S3를 사용
로컬 환경에선 실제 버킷을 사용하지 않고 AWS S3 API와 호환이 가능한 MinIO를 사용
- 로컬 환경에서 개발 및 테스트할 때 사용
- 기사의 메인 및 프로필 이미지를 저장하는 공간으로 활용됨

개발 환경에서 E2E 테스트 설정

개발환경에서 테스트 실행하려면 빌드된 Next.js를 실행해야함

$ npm run build && npm start

E2E 테스트를 실행하기 전 DB의 테스트 데이터를 초기화하자. (이후 테스트의 영향을 미치기 때문)

$ npm run prisma:reset

E2E 테스트 실행

초기 설정을 사용하면 헤드리스 모드로 E2E 테스트를 실행하기 때문에 브라우저는 나타나지 않음

$ npx playwright test
$ npx playwright test Login.spec.ts // 특정 테스트 파일만 테스트 실행

테스트 결과를 리포트로 생성하고 싶다면 npx playwright show-report 를 실행
- 생성된 리포트는 http://localhost:9223/ 에서 확인 가능

플레이라이트 검사 도구를 활용한 디버깅

E2E 테스트를 작성하다보면 기대한것과 다르게 테스트가 통과되지 않을 떄가 있음
이럴 땐 플레이라이트 검사 도구로 원인을 파악해야 한다.
테스트를 실행하는 커맨드에 --debug 옵션을 붙이면 headed 모드로 테스트가 시작됨
- 브라우저를 열어서 육안으로 자동화된 UI 테스트를 확인할 수 있는 모드
검사 도구를 사용하면 실행 중인 테스트 코드를 보면서 UI가 어떻게 조작되는지 확인 가능
좌측 상단에 녹색 삼각형 재생 아이콘을 클릭하면 UI 테스트 시작됨
재생 아이콘 우측에 녹색 화살표 형태의 스텝 오버 아이콘을 클릭하면 한 줄 씩 테스트 코드가 실행됨

$ npx playwright test Login.spec.ts --debug

도커 컴포즈를 사용하는 E2E 테스트

다른 테스트와 다르게 초기에 컨테이너를 빌드하는 시간이 필요
CI용으로 작성한 것

$ npm run docker:e2e:build && npm run docker:e2e:ci

로그인 기능 E2E 테스트

로그인 여부에 따라 애플리케이션이 기대한 대로 작동하는지 검증
이를 검증하려면 로그인한 후에 특정 작업을 수행하는 인터렉션을 자주 사용해야 한다.
로그인 상태와 연관된 기능 테스트를 위해 반복적인 작업을 공통화하는것이 중요

등록 완료된 사용자로 로그인하기

로그인하는 인터렉션을 함수로 만들어 공통화

// e2e/utils.ts
export async function login({
  page,
  userName = "JPub",
}: {
  page: Page;
  userName?: UserName;
}) {
  const user = getUser(userName);
  await page.getByRole("textbox", { name: "메일주소" }).fill(user.email);
  await page.getByRole("textbox", { name: "비밀번호" }).fill(user.password);
  await page.getByRole("button", { name: "로그인" }).click();
}

export function url(path: string) {
  return `http://localhost:3000${path}`;
}

로그인 상태에서 로그아웃

로그아웃 인터렉션도 동일하게 함수로 만들어 공통화

// e2e/utils.ts
export async function logout({
  page,
  userName = "JPub",
}: {
  page: Page;
  userName?: UserName;
}) {
  const user = getUser(userName);
  const loginUser = page.locator("[aria-label='로그인한 사용자']").getByText(user.name)
  await loginUser.hover(); // 마우스를 올려 로그아웃 버튼이 나타나게 함
  await page.getByText("로그아웃").click()
}

로그인 상태가 아니면 로그인 화면으로 리다이렉트 시키기

미로그인 사용자가 해당 페이지에 접근하면 로그인 화면으로 리다이렉트시켜서 로그인을 요청하는 플로우
이 작업도 대부분 테스트에서 필요한것이라 함수로 공통화
로그인 상태가 아니면 접근할 수 없는 페이지에는 assertUnauthorizedRedirect 함수로 미로그인 사용자가 리다이렉트 됐는지 검증

export async function assertUnauthorizedRedirect({
  page,
  path
}: {
  page: Page;
  path: string;
}) {
  // 지정된 페이지에 접근
  await page.goto(url(path));
  // 리다이렉트될 때까지 기다림
  await page.waitForURL(url("/login"));
  // 로그인 페이지로 이동했는지 확인
  await expect(page).toHaveTitle("로그인 | Tech Posts");
}

test("로그인 상태가 아니면 로그인화면으로 리다이렉트된다.", async ({ page }) => {
  const path = "/my/posts"; // 접근할 URL 경로
  await assertUnauthorizedredirect({ page, path })
})

로그인 후 리다이렉트 이전화면으로 돌아가기

예제 코드
로그인 후에 리다이렉트 전 페이지로 돌아가는지 검증

if (err instanceof UnauthroizedError) {
  session.redirectUrl = ctx.resolvedUrl;
  return { redirect: { permanent: false, destination: "/login" } };
}

test.describe("로그인 페이지", () => {
  const path = "/login";
  
  test("로그인 성공 시 리다이렉트 이전 페이지로 돌아간다", async ({ page }) => {
    await page.goto(url("/my/posts"));
    await expect(page).toHaveURL(url(path)); //로그인 화면으로 리다이렉트됨
    await login({ page }); // 로그인 인터렉션을 실행하는 유팉 함수
    await expect(page).toHaveURL(url("/my/posts"));
  })
})

프로필 기능 E2E 테스트

UI를 조작해서 프로필 갱신 API 요청을 발생시킴
API Routes가 작동하고 DB 서버에 값이 저장됨
세션에 저장된 값이 갱신됨
새로운 페이지 제목은 갱신된 세션값을 참조

getServerSideProps로 로그인한 사용자 정보 취득하기

서버 사이드 렌더링을 위한 데이터 취득 함수인 getServerSideProps 는 로그인 상태를 검사하는 고차함수(withLogin) 에 래핑되어있음
인수인 user에는 로그인한 사용자의 정보가 저장됐는데, 해당 로그인 정보를 기반으로 페이지의 데이터를 요청하거나 프로필 정보를 취득한다.
user 객체는 세션에 저장된 정보를 불러옴

Page.getPageTitle = PageTitle(
  ({ data }) => `${data?.authorName}님의 프로필 편집`
);

// 로그인 상태 확인을 포함한 getServerSideProps
export const getServerSideProps = withLogin<Props>(async ({ user }) => {
  return {
  // 프리즈마 클라이언트를 래핑한 함수를 통해 데이터베이스에서 데이터를 취득
    profile: await getMyProfileEdit({ id: user.id }),
    authorName: user.name // 제목에 사용할 유저명을 Props에 포함시킴
  }
})

프로필 정보를 갱신하는 API Routes

Next.js는 API Routes라는 웹 API 구현 기능을 제공함
UI를 조작해 비동기로 데이터를 취득하거나 갱신하는 요청을 받았을 때 서버 프로세스에서 작업을 처리하여 JSON 같은 형식으로 API 응답을 반환한다.
"대부분 코드가 프리즈마 의존성있는 코드라 일단 스킵"

import { expect, test } from '@playwright/test';
import { UserName } from '../prisma/fixtures/user';
import { login, url } from './util';

test.describe("프로필 편집 페이지", () => {
  const path = "/my/profile/edit";
  const userName: UserName = "User-MyProfileEdit";
  const newName = "NewName";
  
  test("프로필을 편집하면 프로필에 반영된다.", async ({ page }) => {
    await page.goto(url(path));
    await login({ page, userName });
    // 여서부터 프로필 편집 화면
    await expect(page).toHaveURL(url(path));
    await expect(page).toHaveTitle(`${userName}님의 프로필 편집`);
    await page.getByRole("textbox", { name: "사용자명" }).fill(newName);
    await page.getByRole("button", { name: "프로필 변경하기" }).click();
    await page.waitForURL(url("/my/posts"));
    // 페이지 제목에 방금 입력한 이름이 포함됨
    await expect(page).toHaveTitle(`${newName}님의 기사 목록`);
    await expect(page.getByRole("region", { name: 프로필" })).toContainText(newName);
    await expect(page.locator("[aria-label='로그인한 사용자']")).toContainText(newName);
    
  })
})

Like 기능 E2E 테스트

기획
- 로그인한 사용자만 Like를 누를 수 있다.
- 단, 자신이 작성한 기사에는 누를 수 없다.
검증
- 다른 사람이 작성한 기사에는 Like를 누를 수 있어야 한다.
- 자신의 기사에는 Like를 누를 수 없어야 한다.

다른 사람이 작성한 기사에는 Like 버튼을 누를 수 있어야 한다.

test("다른 사람의 기사에는 Like 할 수 있다.", async ({ page }) => {
  await page.goto(url("/login"));
  await login({ page, userName: "Jpub" });
  await expect(page).toHaveURL(url("/"));
  // 여기서부터 기사 목록 페이지
  await page.goto(url("/posts/10"));
  const buttonLike = page.getByRole("button", { name: "Like" });
  const buttonText = page.getByTestId("likeStatus");
  // like 버튼이 활성화되고, 현재 Like 수는 0
  await expect(buttonLike).toBeEnabled();
  await expect(buttonLike).toHaveText("0");
  await expect(buttonText).toHaveText("Like");
  await buttonLike.click();
  // like를 클릭하면 카운트가 1증가하고 이미 like 누른 상태가 된다.
  await expect(buttonLike).toHaveText("1");
  await expect(buttonText).toHaveText("Liked");
})

본인이 작성한 기사에는 like 버튼을 누를 수 없다.

test("본인이 작성한 기사에는 Like 할 수 없다.", async ({ page }) => {
  await page.goto(url("/login"));
  await login({ page, userName: "Jpub" });
  await expect(page).toHaveURL(url("/"));
  // 여기서부터 기사 목록 페이지
  await page.goto(url("/posts/90"));
  const buttonLike = page.getByRole("button", { name: "Like" });
  const buttonText = page.getByTestId("likeStatus");
  // like 버튼이 비활성화되고, Like 문자도 사라짐
  await expect(buttonLike).toBeDisabled();
  await expect(buttonText).not.toHavetext("Like");
})

신규 작성 페이지 E2E 테스트

이른바 CRUD라 불리는 기능의 페이지 테스트
CRUD 기능 테스트는 다른 테스트에 영향을 미치지 않는지 세심히 살펴봐야 한다.
기본적으로 Publish 기능 테스트는 새로운 기사를 작성한 후 해당 기사를 대상으로 CRUD해야 한다.

신규 작성 페이지에 접근해 컨텐츠를 입력하는 함수

투고 기능의 E2E 테스트에는 새 기사를 작성하는 작업을 여러 번 실행해야 한다.
컨텐츠 내용은 신경쓰지 말고 필수 입력 항목만 채우는 인터렉션 함수를 만든다.
다른 테스트에 영향을 미치지 않도록 재사용 가능한 기사 작성 함수를 만들어보자.

//e2e/postUtils.ts
export async function gotoAndFillPostContents({
  page,
  title,
  userName,
}: {
  page: Page;
  title: string;
  userName: UserName;
}) {
  await page.goto(url("/login"));
  await login({ page, userName });
  await expect(page).toHaveURL(url("/"));
  await page.goto(url("/my/posts/create"));
  await page.setInputFiles("data-testid=file", [
    "public/__mocks__/images/img01.jpg",
  ]);
  await page waitForLoadState("networkidle", { timeout: 30000 });
  await page.getbyRole("textbox", { name: "제목" }).fill(title);
}

신규 기사를 비공개 상태로 저장하는 함수

신규 기사를 비공개 상태로 저장하는 작업도 여러 번 실행되는 인터렉션

//e2e/postUtils.ts
export async function gotoAndCreatePostAsDraft({
  page,
  title,
  userName,
}: {
  page: Page;
  title: string;
  userName: UserName;
}) {
  await gotoAndFillPostContents({ page, title, userName });
  await page.getByRole("button", { name: "비공개 상태로 저장" }).click();
  await page.waitForNavigation();
  await expect(page).toHaveTitle(title);
}

신규 기사를 공개하는 함수

//e2e/postUtils.ts
export async function gotoAndCreatePostAsPublish({
  page,
  title,
  userName,
}: {
  page: Page;
  title: string;
  userName: UserName;
}) {
  await gotoAndFillPostContents({ page, title, userName });
  await page.getByText("공개 여부").click();
  await page.getByRole("button", { name: "공개하기" }).click();
  await page.getByRole("button", { name: "" }).click();
  await page.waitForNavigation();
  await expect(page).toHaveTitle(title);
}

재사용되는 유틸 함수들을 활용하여 E2E 테스트 작성하기

expect 함수를 사용하는 단언문도 앞서 만든 함수들에 포함됐으므로 검증이 간단해진다.

//e2e/MyPostscreate.spec.ts
import { test } from '@playwright/test';
import { UserName } from '../prisma/fixtures/user';
import {
  gotoAndCreatePostAsDraft,
  gotoAndCreatePostAsPublish
} from './postUtil';

test.describe("신규 기사 페이지", () => {
  const path = "/my/posts/create";
  const userName: UserName = "JPub";
  
  test("신규 기사를 비공개 상태로 저장할 수 있다.", async ({ page }) => {
    const title = "비공개 상태로 저장하기 테스트";
    await gotoAndCreatePostAsDraft({ page, title, userName });
  })
  
  test("신규 기사를 공개할 수 있다.", async ({ page }) => {
    const title = "공개하기 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
  })
})

기사 편집 페이지 E2E 테스트

기사를 편집했을 때 기사 목록에 미치는 영향과 기사를 삭제하는 기능에 대한 E2E 테스트

공통 함수

작성된 기사 페이지로 이동한 뒤 편집 페이지로 이동하는 인터렉션 함수

export async function gotoEditPostPage({
  page,
  title,
}: {
  page: Page;
  title: string;
}) {
  await page.getByRole("link", { name: "편집하기" }).click();
  await page.waitForNavigation();
  await expect(page).toHaveTitle(`기사 편집 | ${title}`);
}

검증

비공개 상태로 저장한 기사를 편집해 내용이 갱신되는지 검증
비공개 상태로 저장한 기사 공개 상태로 변경할 수 있는지 검증
공개된 기사를 편집하고 비공개 상태로 변경할 수 있는지 검증
공개된 기사를 삭제할 수 있는지 검증

import { expect, test } from "@playwright/test";
import { checkA11y, injectAxe } from "axe-playwright";
import { UserName } from "../prisma/fixtures/user";
import {
  gotoAndCreatePostAsDraft,
  gotoAndCreatePostAsPublish,
  gotoEditPostPage,
} from "./postUtil";
import { assertUnauthorizedRedirect, url } from "./util";

test.describe("기사 편집 페이지", () => {
  const path = "/my/posts/1/edit";
  const userName: UserName = "JPub";

  test("로그인 상태가 아니면 로그인 화면으로 리다이렉트된다", async ({ page }) => {
    await assertUnauthorizedRedirect({ page, path });
  });

  test("비공개 기사를 편집할 수 있다", async ({ page }) => {
    const title = "비공개 편집 테스트";
    const newTitle = "비공개 편집 테스트 갱신 완료";
    await gotoAndCreatePostAsDraft({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByRole("textbox", { name: "제목" }).fill(newTitle);
    await page.getByRole("button", { name: "비공개 상태로 저장" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(newTitle);
  });

  test("비공개 기사를 공개할 수 있다", async ({ page }) => {
    const title = "비공개 기사 공개 테스트";
    await gotoAndCreatePostAsDraft({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByText("공개 여부").click();
    await page.getByRole("button", { name: "공개하기" }).click();
    await page.getByRole("button", { name: "네" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(title);
  });

  test("공개된 기사를 비공개할 수 있다", async ({ page }) => {
    const title = "기사 비공개 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByText("공개 여부").click();
    await page.getByRole("button", { name: "비공개 상태로 저장" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(title);
  });

  test("공개된 기사를 삭제할 수 있다", async ({ page }) => {
    const title = "기사 삭제 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
    await gotoEditPostPage({ page, title });
    await page.getByRole("button", { name: "삭제하기" }).click();
    await page.getByRole("button", { name: "네" }).click();
    await page.waitForNavigation();
    await expect(page).toHaveTitle(`${userName}님의 기사 목록`);
  });

  test("접근성 검증", async ({ page }) => {
    await page.goto(url(path));
    await injectAxe(page as any);
    await checkA11y(page as any);
  });
});

기사 목록 페이지 E2E 테스트

신규 기사가 작성되면 기사 목록에 어떤 영향을 미치는지에 대한 E2E 테스트
기사 목록은 메인 페이지와 마이 페이지 두 곳에 존재
- 비공개 상태로 저장한 기사는 작성자 외 열람이 불가능하므로 메인 페이지에선 노출되지 않아야함

검증

마이 페이지의 기사 목록에 신규 기사가 추가됐는지 검증
- 비공개 상태로 저장한 기사와 공개 상태로 저장한 기사 모두 목록에 추가돼야함
메인 페이지의 기사 목록에 신규 기사가 추가됐는지 검증
- 비공개 상태로 저장한 기사는 목록에 안보여야함

import { expect, test } from "@playwright/test";
import { checkA11y, injectAxe } from "axe-playwright";
import { UserName } from "../prisma/fixtures/user";
import {
  gotoAndCreatePostAsDraft,
  gotoAndCreatePostAsPublish,
} from "./postUtil";
import { assertUnauthorizedRedirect, login, url } from "./util";

/* 코드 10-15
test("로그인 상태가 아니면 로그인 화면으로 리다이렉트된다", async ({ page }) => {
  const path = "/my/posts";
  await assertUnauthorizedRedirect({ page, path });
});
*/

test.describe("게재된 기사 목록 페이지", () => {
  const path = "/my/posts";
  const userName: UserName = "JPub";

  test("로그인 상태가 아니면 로그인 화면으로 리다이렉트된다", async ({ page }) => {
    await assertUnauthorizedRedirect({ page, path });
  });

  test("자신의 프로필을 열람할 수 있다", async ({ page }) => {
    await page.goto(url(path));
    await login({ page });
    await expect(page).toHaveURL(url(path));
    const profile = page.getByRole("region", { name: "프로필" });
    await expect(profile).toContainText("JPub");
  });

  test("신규 기사를 비공개 상태로 저장하면 게재된 기사 목록에 기사가 추가된다", async ({
    page,
  }) => {
    const title = "비공개로 저장된 기사 목록 테스트";
    await gotoAndCreatePostAsDraft({ page, title, userName });
    await page.goto(url(path));
    await expect(page.getByText(title)).toBeVisible();
  });

  test("신규 기사를 공개 상태로 저장하면 게재된 기사 목록에 기사가 추가된다", async ({
    page,
  }) => {
    const title = "공개 상태로 저장된 기사 목록 테스트";
    await gotoAndCreatePostAsPublish({ page, title, userName });
    await page.goto(url(path));
    await expect(page.getByText(title)).toBeVisible();
  });

  test("접근성 검증", async ({ page }) => {
    await page.goto(url(path));
    await injectAxe(page as any);
    await checkA11y(page as any);
  });
});

불안정한 테스트 대처 방법

흔히 E2E 테스트는 안정적이지 않다고 생각함
- 불안정한 테스트는 네트워크 지연이나, 메모리 부족에 의한 서버 응답 지연 등 다양한 원인으로 발생함
- 테스트 실행 순서의 영향으로 의도하지 않은 상태에서 테스트를 시작하여 문제가 발생하기도 함
이런 다양한 원인으로 불안정한 테스트가 발생하는 것은 E2E 테스트에선 피할 수 없는 문제
- 몇가지 대처 방법은 존재한다.

실행할 때마다 데이터베이스 재설정하기

DB를 사용하는 E2E 테스트는 테스트를 실행하면 데이터가 변경된다.
일관성있는 결과를 얻으려면 테스트 시작 시점의 상태는 항상 동일해야 한다.
- 테스트를 실행할 때마다 시드 스크립트로 초깃값을 재설정 해야함?

테스트마다 사용자를 새로 만들기

프로필 편집 기능을 테스트한다고 기존 사용자 정보를 변경하면 안됨
테스트에선 각 테스트를 위해 생성한 사용자를 사용해야 한다.
테스트가 끝나면 테스트용 사용자는 제거

테스트 간 리소스가 경합하지 않도록 주의

CRUD 기능의 E2E 테스트처럼 각 테스트에서 매번 새로운 리소스를 작성하도록 해야함
플레이라이트 테스트는 병렬처리되기 때문에 테스트 실행 순서를 보장할 수 없다.
불안정한 테스트가 발견되면 리소스 경합이 발생하고 있는지 검토해야함

리소스 경합이란?

여러 프로세스나 스레드가 동시에 동일한 자원(예: CPU, 메모리, 디스크, 네트워크 등)에 접근하려고 할 때 발생하는 문제를 말한다

빌드한 애플리케이션 서버로 테스트하기

next.js 애플리케이션에서 개발할 때는 개발 서버에서 디버깅하며 코드를 작성하지만 E2E 테스트는 개발 서버에서 실행하지 않도록 주의해야 한다.
빌드한 Next.js 애플리케이션은 개발 서버와 다르게 동작하기 때문
또한 개발 서버는 응답 속도도 느려서 불안정한 테스트의 원인이 되기도함

비동기 처리 대기하기

예를들어 이미지 업로드 인터렉션이 있다면, 네트워크 통신이 완료될 때까지 기다려야 한다.
이처럼 시간이 걸리는 작업은 단위 테스트에서 했던것처럼 비동기 처리 응답을 대기해야 한다.
만약 조작할 요소가 존재하고 문제없이 인터렉션이 할당됐음에도 테스트가 실패한다면 비동기 처리를 제데로 대기하는지 확인해야함

--debug로 테스트 실패 원인 조사하기

불안정한 테스트의 원인을 파악하려면 디버거를 활용해야함
플레이라이트는 실행할 때 --debug 를 붙이면 디버거를 실행할 수 있음
직접 디버거에서 한 줄 씩 작동을 확인하며 실패 원인을 파악해보자.

CI 환경과 CPU 코어 수 맞추기

로컬에서 테스트를 실행하는 경우 모두 통과하지만 CI 환경에서는 실패하기도 한다.
이 경우 로컬 기기의 CPU 코어 수와 CI 코어수가 동일한지 체크해야 한다.
플레이라이트나 제스트는 코어 수를 명시적으로 지정하지 않으면 실행 환경에서 실행 가능한 만큼 테스트 스위트를 병렬 처리한다.
- 즉, 병렬처리되는 숫자는 실행 환경의 CPU 코어 수 떄문에 변동됨
CPU 코어 수가 변도되지 않도록 고정하는 설정을 추가한다. (테스트 러너에 지정할 수 있음)
CI의 코어 수에 맞춰 설정한 후, 로컬에서도 모든 테스트가 통과되면 문제 해결
만약 해결되지 않은 경우 대기 시간의 상한을 늘려보자.
- 전체적으로 보면 CI에서 테스트가 실패해 계속 재시도 하는 것보다 시간을 단축시킬 수 있다.

테스트 범위 최소화

상황에 따라 E2E 테스트로 검증하는 것이 적절한지 살펴봐야 한다.
테스트 피라미드 상층부에 가까울 수록 실제 상황과 유사한 테스트가 가능하지만, 반대로 불안정성이 증가하고 실행시간도 길어짐
E2E 테스트를 더 넓은 범위의 통합 테스트로 대체가능하면 더 적은 비용으로 안정적인 테스트를 할 수 있다.
검증 내용에 맞는 최적의 테스트 범위를 찾아야 불안정한 테스트가 생길 가능성이 낮아진다.

Previous시각적 회귀 테스트 NextGithub Actions 설정

Last updated 10 months ago