단위와 통합과 브라우저 테스트를 주방 검사처럼 나누기

AI가 ‘테스트가 통과했습니다’라고 말해도 공개 화면에서 버튼이 보이지 않을 수 있습니다. 실행한 테스트가 계산 함수만 확인했을 뿐 모바일 화면이나 서버 연결은 보지 않았을 수 있기 때문입니다. 통과라는 말보다 무엇을 어떤 조건에서 검사했는지 읽어야 합니다.

테스트는 입력이나 행동을 주고 기대 결과와 같은지 자동으로 확인하는 코드입니다. 식당에서 소스 맛만 보는 검사, 완성된 한 접시를 확인하는 검사, 손님이 주문하고 받는 전 과정을 확인하는 검사가 다른 것처럼 테스트도 범위를 나눕니다.

단위 테스트는 가장 작은 조리 단위를 본다

단위 테스트는 함수나 모듈처럼 작은 코드 한 부분을 빠르게 확인합니다. 가격 합계 함수에 1000과 500을 넣었을 때 1500이 나오는지 검사하는 식입니다. 실패하면 살펴볼 범위가 작아 원인을 빨리 찾을 수 있습니다.

import { expect, test } from "vitest";

test("배송비를 더한다", () => {
  expect(10000 + 3000).toBe(13000);
});

Vitest 공식 시작 문서도 함수를 불러 입력을 주고 ‘expect’로 결과를 비교하는 작은 예시를 보여 줍니다. 여기서 expect는 바라는 결과를 선언하는 검사 표현입니다. 이 테스트가 통과해도 실제 결제 금액, 화면 표시, 네트워크 연결까지 확인한 것은 아닙니다.

통합 테스트는 여러 부품의 연결을 본다

통합 테스트는 화면과 상태, 서버와 데이터베이스처럼 둘 이상의 부분이 함께 작동하는지 확인합니다. 주방에서 소스와 면을 따로 검사한 뒤 실제 한 접시로 조합해 보는 단계와 비슷합니다. 각 부품은 정상이어도 이름이나 데이터 형식이 어긋나 연결에서 실패할 수 있습니다.

범위를 무조건 크게 만들면 느리고 실패 원인을 찾기 어렵습니다. 한 기능의 중요한 경계만 고릅니다. 회원가입이라면 입력 검증, 서버 요청, 성공 응답 뒤 화면 변화까지 묶되 실제 이메일 발송이나 결제는 안전한 시험 대역을 쓰는 방법을 검토합니다.

브라우저 테스트는 사용자의 길을 따라간다

브라우저 테스트는 실제 브라우저에서 페이지를 열고 클릭하고 화면 결과를 확인합니다. 끝에서 끝까지 보는 테스트를 E2E라고도 하며, 사용자의 주요 흐름을 실제 환경에 가깝게 검사합니다. Playwright는 Chromium, WebKit, Firefox와 모바일 화면 모사를 지원하는 브라우저 테스트 도구입니다.

로그인 버튼이 키보드로 눌리는지, 모바일에서 가려지지 않는지, 이동 뒤 주소와 제목이 맞는지는 작은 함수 검사만으로 놓칠 수 있습니다. 반면 모든 문구와 픽셀을 브라우저 테스트에 넣으면 사소한 변경에도 자주 깨집니다. 회원가입 완료, 계산 결과 표시, 결제 직전 확인처럼 사업에 중요한 길을 우선합니다.

테스트 통과는 적힌 기대만 확인한다

테스트는 작성자가 적지 않은 위험을 알아서 찾아내지 않습니다. ‘버튼이 존재한다’만 검사하면 버튼을 눌렀을 때 저장되는지는 모릅니다. 가짜 서버 응답만 쓰면 실제 배포 서버의 권한과 환경변수 문제도 남습니다.

• 테스트 이름에 사용자 행동과 기대 결과를 함께 씁니다.
• 정상 입력뿐 아니라 빈 값과 실패 응답도 확인합니다.
• 외부 서비스는 실제 호출 여부와 가짜 응답 범위를 구분합니다.
• 시간과 날짜, 화면 너비처럼 결과를 바꾸는 조건을 고정합니다.
• 실패한 테스트를 삭제하거나 건너뛰기 전에 이유를 기록합니다.
• 수정 뒤 관련 테스트와 전체 테스트를 모두 실행합니다.

좋은 검사 순서는 빠른 것에서 실제 환경으로 간다

먼저 타입 검사와 단위 테스트로 단순 실수를 잡습니다. 다음으로 통합 테스트에서 데이터 연결을 보고, 마지막으로 핵심 흐름을 브라우저에서 확인합니다. 빠른 검사는 자주 실행하고 느린 검사는 배포 전과 자동화 과정에서 놓치지 않게 배치합니다.

실패가 나면 한꺼번에 다시 실행하지 말고 첫 실패의 테스트 이름, 기대값, 실제값을 읽습니다. 같은 테스트가 실행할 때마다 달라진다면 시간, 네트워크, 공유 데이터가 고정됐는지 봅니다. 가끔 통과하는 테스트는 안전 신호가 아니라 불안정한 검사일 수 있습니다.

테스트 데이터에는 안전한 경계가 필요하다

실제 고객 이메일, 카드번호, 운영 API 키를 테스트 파일에 넣지 않습니다. 테스트 계정과 가짜 값을 쓰고 운영 데이터베이스와 분리합니다. 삭제, 환불, 이메일 발송 같은 행동은 테스트 환경임을 확인한 뒤 실행합니다.

스크린샷과 테스트 보고서에도 개인정보가 남을 수 있습니다. 자동화 결과를 공유하기 전에 입력값, 주소, 토큰을 확인하고 보관 기간을 정합니다. 테스트가 끝난 뒤 만들어진 가짜 데이터와 계정 정리 절차도 설계의 일부입니다.

오늘 바로 해볼 작은 실습

코드를 실행하지 않고 평소 쓰는 로그인 화면을 대상으로 검사 문장만 만듭니다.

1. 단위 검사로 ‘이메일 형식 함수가 빈 값을 거절한다’를 적습니다.
2. 통합 검사로 ‘서버 성공 응답 뒤 사용자 이름이 보인다’를 적습니다.
3. 브라우저 검사로 ‘모바일에서 로그인하고 첫 화면으로 이동한다’를 적습니다.
4. 각 문장에 입력, 행동, 기대 결과를 표시합니다.
5. 실제 외부 호출이 필요한 항목과 가짜 응답으로 충분한 항목을 나눕니다.
6. 개인정보나 결제가 들어가는 항목 옆에 테스트 환경 조건을 씁니다.

출처를 모르는 테스트 명령을 운영 프로젝트에서 바로 실행하지 마세요. 특히 삭제와 결제, 대량 이메일을 포함한 테스트는 대상 환경과 계정을 설명할 수 없으면 멈춥니다. 테스트 수가 많다는 사실보다 중요한 사용자 길을 서로 다른 층에서 확인하는지가 더 중요합니다.