「프론트엔드 테스트 제대로 하기」 시리즈의 부록입니다. 본문을 읽다가 낯선 용어를 만나면 언제든 이 페이지로 돌아오세요. 전체 목차 보기

프론트엔드 테스트를 배우다 보면 낯선 용어가 쏟아집니다. mock과 stub은 뭐가 다른지, getBy와 queryBy는 언제 갈리는지, 커버리지 숫자는 왜 그대로 믿으면 안 된다는 건지 — 그런 용어들을 이 페이지 하나에 전부 모았습니다. 항목마다 “이게 뭔지"에서 멈추지 않고 “왜 필요한지”, “언제 쓰는지"까지 담았어요.

쓰는 법은 두 가지입니다. 낯선 단어를 만났을 때 찾아보는 사전으로 써도 되고, 위에서 아래로 그냥 읽어도 됩니다 — 용어를 사전 순이 아니라 배우는 순서(챕터순)로 배치해서, 처음부터 끝까지 읽으면 그대로 프론트엔드 테스트의 지형도가 그려지거든요. 더 깊게 보고 싶으면 각 용어 끝의 링크로 해당 편에 다녀오세요.

자주 찾는 질문은 바로 갈 수 있게 이어뒀습니다.

기초 개념 (0장)

무엇을 배우든 가장 먼저 만나는, 테스트의 큰 그림 용어들입니다.

단위 테스트 (unit test) 함수나 모듈처럼, 프로그램을 이루는 가장 작은 조각 하나만 떼어내 검증하는 테스트입니다. 입력을 넣었을 때 기대한 값이 나오는지를 확인하죠. 네트워크나 데이터베이스, 브라우저 같은 외부 요소 없이 순수한 로직만 보기 때문에 실행이 아주 빠르고(보통 밀리초 단위), 실패했을 때 “어느 함수가 잘못됐는지"가 곧바로 좁혀집니다. 그래서 테스트 피라미드에서 가장 아래, 가장 많이 두는 층이에요. → 자세히: 4편

통합 테스트 / 컴포넌트 테스트 (integration / component test) 단위 테스트가 조각 하나를 본다면, 통합·컴포넌트 테스트는 여러 조각이 맞물려 함께 돌아가는지를 봅니다. 프론트엔드에서는 주로 화면 컴포넌트가 대상인데, 내부 구현이 아니라 “사용자가 보고 조작하는 결과"를 기준으로 검증하는 게 핵심이에요. 예를 들어 검색창에 글자를 입력하면 결과 목록이 바뀌는지를, 실제 사용자처럼 확인합니다. → 자세히: 7편

E2E 테스트 (End-to-End) 사용자가 실제로 하는 흐름 전체를 진짜 브라우저에서 처음부터 끝까지 재현하는 테스트입니다. 페이지 접속 → 검색어 입력 → 결과 확인처럼, 여러 화면과 네트워크가 얽힌 시나리오를 통째로 검증하죠. 가장 느리고 관리 비용도 크지만, 실제 사용 환경에 가장 가까워서 “정말 동작하는가"에 대한 신뢰가 제일 높습니다. 그래서 많이 만들기보다는 핵심 경로만 골라 굵게 가져갑니다. → 자세히: 11편 (연재 예정)

커버리지 (coverage) 테스트를 한 번 돌렸을 때, 전체 코드 중 실제로 실행된 부분이 몇 %인지를 나타내는 숫자입니다. 테스트 도구가 자동으로 계산해줘요. 주의할 점은, “실행됐다"와 “제대로 검증됐다"는 다르다는 거예요. 코드를 지나가기만 하고 아무것도 확인하지 않아도 커버리지는 올라가거든요. 그래서 커버리지는 목표로 삼기보다, “어디가 전혀 테스트되지 않았는지"를 찾는 참고 지표로 쓰는 게 맞습니다. 세는 방식(라인·브랜치)에 따라 숫자가 달라지는데, 이 구분은 아래 4장의 라인/브랜치 커버리지 항목에서 정리합니다. → 자세히: 2편, 18편 (연재 예정)

스모크 테스트 (smoke test) “일단 켜지긴 하는가"만 확인하는 최소한의 테스트입니다. 페이지가 에러 없이 뜨는지, 핵심 요소가 화면에 나타나는지 정도만 보죠. 세세한 동작까지 검증하지는 않지만, 큰 사고(전체가 하얗게 깨지는 등)를 값싸게 걸러내는 1차 방어선입니다. 이름은 전자기기에 처음 전원을 넣고 연기가 나는지 보던 데서 왔어요.

회귀 (regression) 잘 동작하던 기능이 코드를 바꾼 뒤 다시 망가지는 현상을 말합니다. 새 기능을 넣거나 리팩터링을 하다 보면, 전혀 상관없어 보이던 부분이 깨지곤 하죠. 테스트를 갖춰두는 가장 큰 이유가 바로 이 회귀를 자동으로 잡기 위해서입니다. 한 번 고친 버그가 다시 돌아오지 않도록 지켜주는 안전망인 셈이에요.

단위 테스트 도구 (1장)

함수 하나를 검증하는 단계 — Vitest로 단위 테스트를 쓸 때 나오는 용어들입니다.

Vitest 이 시리즈가 쓰는 테스트 러너입니다. 러너는 프로젝트에서 테스트 파일을 찾아 실행하고, 무엇이 통과하고 실패했는지 알려주는 도구예요. Vitest는 Vite 기반 프로젝트와 설정을 공유해 빠르고, 오랫동안 표준이었던 Jest와 API가 거의 호환됩니다 — 그래서 이 페이지의 설명은 Jest 사용자에게도 대부분 그대로 통합니다. → 자세히: 3편

it / test 테스트 하나를 정의하는 함수입니다. it('빈 검색어면 전체를 반환한다', () => { ... })처럼, 첫 인자에 “이 테스트가 무엇을 확인하는지"를 문장으로 적고, 두 번째 인자인 함수 안에 실제 검증 코드를 씁니다. it과 test는 이름만 다르고 하는 일은 같아요. 이 문장이 곧 실패 리포트에 그대로 뜨기 때문에, 설명을 명확히 적어두면 나중에 원인을 훨씬 빨리 찾습니다. → 자세히: 3편

expect + 매처 (matcher) “이 값이 이래야 한다"를 코드로 선언하는 부분입니다. expect(결과).toBe(기대값) 형태로 쓰는데, expect()에 검사할 값을 넣고, 점 뒤에 붙는 toBe·toEqual·toBeInTheDocument 같은 것이 “어떻게 비교할지"를 정하는 매처예요. toBe는 정확히 같은지, toEqual은 내용이 같은지, toBeInTheDocument는 화면에 실제로 있는지를 봅니다. 테스트에 이 단언(assertion)이 하나도 없으면, 코드는 실행돼도 사실상 아무것도 검증하지 못합니다. → 자세히: 3편

describe 서로 관련 있는 테스트 여러 개를 하나로 묶는 그룹입니다. 예를 들어 describe('filterByQuery', ...) 안에 그 함수에 대한 테스트들을 모아두면, 실행 결과가 “filterByQuery › 대소문자를 무시한다"처럼 계층으로 표시돼요. 테스트가 수십 개로 늘어나도 어디서 무엇이 깨졌는지 한눈에 들어오게 해주는 정리 도구입니다. → 자세히: 4편

AAA 패턴 읽기 좋은 테스트를 쓰는 세 단계 뼈대입니다. 준비(Arrange)에서 필요한 데이터와 상태를 만들고, 실행(Act)에서 검사 대상 동작을 한 번 수행하고, 검증(Assert)에서 결과가 기대와 맞는지 확인합니다. 이 순서를 지키면 테스트가 “무엇을 준비해서, 무엇을 했더니, 어떻게 돼야 한다"는 이야기처럼 읽혀요. 순서가 뒤섞인 테스트는 남이(그리고 몇 달 뒤의 나도) 이해하기 어렵습니다. → 자세히: 4편

jsdom Node.js 환경 안에서 브라우저의 DOM(화면 구조)을 흉내 내주는 라이브러리입니다. 진짜 브라우저를 띄우지 않고도 document나 querySelector 같은 것을 쓸 수 있어서, 컴포넌트 테스트를 아주 빠르게 돌릴 수 있죠. 다만 실제 렌더링이나 화면 크기, 애니메이션 같은 부분은 완벽히 재현하지 못합니다. 그래서 “빠른 다수 검증"은 jsdom으로, “진짜 브라우저가 필요한 검증"은 E2E로 나눠 맡깁니다. → 자세히: 3편

vi Vitest가 기본으로 제공하는 도우미 객체입니다. 시간을 마음대로 앞으로 돌리는 가짜 타이머(vi.useFakeTimers()), 호출을 감시하거나 대신 실행하는 가짜 함수(vi.fn()), 모듈 통째로 바꿔치기 같은 기능이 여기 모여 있어요. 테스트하기 까다로운 상황(실제로 3초를 기다려야 하거나, 외부 API를 부르는 코드)을 다룰 때 이 도구들을 꺼내 씁니다. → 자세히: 5편

테스트 더블 (test double) 진짜 객체 대신 세워두는 “대역"들을 통틀어 부르는 말입니다. 영화의 스턴트 대역을 떠올리면 쉬운데, 상황에 따라 종류가 나뉩니다. stub은 정해진 값만 돌려주는 단순 대역, spy는 진짜 동작은 그대로 두되 “몇 번, 어떤 인자로 불렸는지"를 몰래 기록하는 대역, mock은 그 호출이 기대대로 일어났는지까지 검증하는 대역, fake는 가볍게 새로 구현한 대체품(예: 진짜 DB 대신 메모리 배열)입니다. 이걸 구분해서 “딱 필요한 만큼만” 가짜로 바꾸는 게 좋은 테스트의 요령이에요. → 자세히: 6편

스냅샷 테스트 (snapshot) 컴포넌트가 그려낸 결과물을 통째로 파일에 저장해두고, 다음 실행 때 그때와 달라지면 실패로 알려주는 방식입니다. “달라진 것"은 잘 잡지만, 함정이 있어요. 애초에 저장된 그 결과물이 정말 올바른지는 아무도 검증하지 않았다는 점입니다. 그래서 실패했을 때 내용을 꼼꼼히 보지 않고 스냅샷만 갱신하고 넘어가는 습관이 들면, 사실상 아무것도 지켜주지 못하게 됩니다. 남용하지 않는 게 중요합니다. → 자세히: 2편, 16편 (연재 예정)

컴포넌트 테스트 (2장)

화면(컴포넌트)을 사용자 관점으로 테스트할 때 나오는 용어들입니다.

Testing Library 컴포넌트를 테스트용으로 그리고(render), 그려진 화면에서 요소를 찾게(screen) 해주는 도구 모음입니다. React용(React Testing Library)이 가장 유명하지만 Vue·Svelte판도 있고, 철학은 하나예요 — “사용자가 보는 대로 테스트하라”. 이 장의 쿼리·role 같은 용어가 전부 이 도구에서 나옵니다. → 자세히: 7편

쿼리 (getBy / queryBy / findBy) 화면에서 특정 요소를 찾아오는 방법으로, 세 종류가 상황에 따라 나뉩니다. getBy는 요소가 없으면 즉시 에러를 냅니다(있어야 정상인 것에 사용). queryBy는 없으면 조용히 null을 돌려주기 때문에, “이게 화면에 없어야 한다"를 확인할 때 씁니다. findBy는 요소가 나타날 때까지 잠시 기다려주므로, 데이터를 불러온 뒤 비동기로 나타나는 것에 알맞아요. 이 셋을 구분해 쓰는 것만으로도 테스트가 훨씬 안정적이 됩니다. → 자세히: 7편

role / 접근 가능한 이름 (accessible name) role은 요소의 의미(버튼인지, 제목인지, 검색창인지)이고, 접근 가능한 이름은 그 요소를 가리키는 이름(예: “검색” 버튼)입니다. 둘 다 스크린 리더가 사용자에게 읽어주는 정보인데, 좋은 테스트도 바로 이 정보로 요소를 찾습니다. CSS 클래스나 태그 구조가 아니라 “화면에서 어떤 의미로 보이는가"로 찾기 때문에, 테스트를 이 방식으로 쓰면 그 자체가 접근성 점검이 되는 셈이에요. → 자세히: 7편, 10편 (연재 예정)

user-event / fireEvent 둘 다 사용자의 상호작용을 테스트에서 흉내 내는 도구입니다. fireEvent는 “change 이벤트 하나 발생” 식으로 낮은 수준의 이벤트를 직접 쏘는 옛 방식이고, user-event는 실제 사람의 행동을 더 충실히 재현합니다. 예를 들어 타이핑 한 번에도 포커스가 옮겨가고, 키를 하나씩 눌렀다 떼고, 그에 따라 값이 바뀌는 과정을 순서대로 밟죠. 실제 사용에 가까운 결과를 얻고 싶으면 대부분 user-event를 쓰는 게 좋습니다. → 자세히: 8편

MSW (Mock Service Worker) 테스트나 개발 중에 나가는 네트워크 요청을 중간에서 가로채, 미리 준비한 가짜 응답을 돌려주는 도구입니다. 서버 코드를 건드리거나 실제 백엔드를 띄우지 않고도, 성공·실패·느린 응답 같은 다양한 상황을 마음대로 만들어볼 수 있어요. 우리 코드 입장에서는 진짜 서버와 대화하는 것과 구분이 안 되기 때문에, 실제와 거의 같은 조건으로 테스트할 수 있습니다. 같은 설정을 개발용·데모용으로도 재활용할 수 있는 게 장점이에요. → 자세히: 9편

E2E & Playwright (3장)

진짜 브라우저에서 사용자 흐름 전체를 검증하는 단계의 용어들입니다.

Playwright 진짜 브라우저(크로미움·파이어폭스·웹킷)를 코드로 조종해 E2E 테스트를 돌리는 도구입니다. 페이지를 열고, 입력하고, 클릭하고, 확인하는 전 과정을 자동화해요. 이 장의 나머지 용어들은 대부분, Playwright가 이 자동화를 안정적으로 만들기 위해 내놓은 장치들입니다. → 자세히: 11편 (연재 예정)

로케이터 (locator) “이 요소를 어떻게 찾는가"라는 방법 자체를 담아둔 객체입니다. 요소를 미리 붙잡아 두는 게 아니라, 실제로 클릭하거나 확인하는 그 순간에 다시 찾아가죠. 그래서 화면이 다시 그려지거나 구조가 조금 바뀌어도 잘 버팁니다. 주소를 외워두는 대신 “찾아가는 길"을 들고 다니는 것과 비슷해요. → 자세히: 12편 (연재 예정)

auto-wait (자동 대기) Playwright가 어떤 동작을 하기 전에, 대상 요소가 화면에 나타나고 클릭할 수 있는 상태가 될 때까지 스스로 기다려주는 기능입니다. 덕분에 “3초 기다려라” 같은 임의의 대기 코드를 넣지 않아도 되죠. 이런 고정 대기는 어떤 컴퓨터에서는 충분하고 어떤 컴퓨터에서는 모자라서 테스트를 불안정하게 만드는 주범인데, auto-wait가 그 문제를 상당 부분 없애줍니다. → 자세히: 12편 (연재 예정)

strict mode (엄격 모드) 하나를 가리키려 한 로케이터가 화면에서 여러 요소와 겹쳐 매칭되면, 아무거나 고르지 않고 즉시 실패시키는 안전장치입니다. 얼핏 불편해 보이지만, 조용히 엉뚱한 요소를 눌러서 이상하게 통과하거나 실패하는 것보다 훨씬 낫습니다. “지금 이 조건이 두 개를 가리키니 더 정확히 짚어달라"고 알려주는 셈이라, 결과적으로 테스트를 더 튼튼하게 만들어요. → 자세히: 12편 (연재 예정)

flaky 테스트 코드를 하나도 바꾸지 않았는데 어떤 때는 통과하고 어떤 때는 실패하는, 신뢰할 수 없는 테스트를 말합니다. 원인은 대부분 타이밍(요소가 준비되기 전에 건드림)이나 애매한 셀렉터(여러 요소와 겹침)예요. flaky 테스트를 방치하면 팀이 실패를 무시하게 되고, 그러다 진짜 버그까지 놓치게 됩니다. 그래서 원인을 찾아 확실히 없애는 게 중요합니다. → 자세히: 12편 (연재 예정)

픽스처 (fixture) 여러 테스트가 공통으로 하는 준비 작업(페이지 접속, 로그인, 데이터 세팅 등)을 한 곳에 정의해두고 각 테스트에 자동으로 넣어주는 장치입니다. 덕분에 테스트마다 같은 준비 코드를 복사해 붙이지 않아도 되고, 본문은 “이번엔 무엇을 검증하는가"에만 집중할 수 있어요. 무대에 배우가 오르기 전 소품과 조명을 세팅해두는 스태프 역할이라고 보면 됩니다. → 자세히: 13편 (연재 예정)

storageState 로그인한 상태(쿠키·토큰 등)를 파일 하나에 저장해두고 여러 테스트가 재사용하게 해주는 Playwright 기능입니다. 이게 없으면 테스트마다 매번 로그인 화면을 거쳐야 해서 느리고 번거롭죠. 한 번 로그인해 “출입증"을 만들어두고, 이후 테스트들은 그 증을 들고 바로 입장하는 방식이라고 생각하면 됩니다. → 자세히: 13편 (연재 예정)

트레이스 (trace) 실패한 E2E 테스트가 어떤 단계를 밟았는지, 각 시점의 화면 스냅샷·네트워크 요청·콘솔 로그와 함께 되감아 볼 수 있게 남기는 기록입니다. “내 컴퓨터에선 되는데 CI에서만 깨진다” 같은 답답한 상황에서, 실제로 무슨 일이 있었는지 영상처럼 재생해 원인을 짚을 수 있어요. 자동차 블랙박스와 같은 역할입니다. → 자세히: 14편 (연재 예정)

리트라이 (retry) 테스트가 실패하면 자동으로 몇 번 더 시도해보는 설정입니다. 일시적인 네트워크 지연 같은 진짜 우연을 걸러내는 데는 유용해요. 하지만 재시도해서 통과했다는 건, 그 테스트가 근본적으로 불안정하다는 신호이기도 합니다. 리트라이는 응급 처치일 뿐, “왜 처음에 실패했는가"를 파고들어 원인을 고치는 게 진짜 해결이에요. → 자세히: 14편 (연재 예정)

axe (axe-core) 페이지의 접근성 문제를 규칙에 따라 자동으로 훑어주는 검사 엔진입니다. 색 대비가 부족한 곳, 이름이 없는 버튼, 잘못 쓰인 ARIA 속성처럼 기계가 판단할 수 있는 항목을 걸러줘요. 다만 “이 대체 텍스트가 맥락에 맞는가” 같은 판단은 여전히 사람의 몫입니다. axe는 자동으로 잡을 수 있는 부분을 빠르게 처리해, 사람이 더 중요한 곳에 집중하게 해주는 도구예요. → 자세히: 15편 (연재 예정)

baseline / 시각 회귀 (visual regression) 기준이 되는 화면 스크린샷(baseline)을 저장해두고, 이후 화면을 픽셀 단위로 비교해 달라진 부분을 찾아내는 테스트입니다. CSS 한 줄이 무너뜨린 레이아웃처럼, 코드로는 멀쩡해 보여도 “눈으로 봐야만” 알 수 있는 사고를 잡아줍니다. 다만 의도한 디자인 변경도 “달라짐"으로 잡히기 때문에, 그럴 때는 baseline을 새로 갱신해줘야 해요. → 자세히: 16편 (연재 예정)

자동화 & 품질 (4장)

테스트가 ‘자동으로, 항상’ 돌게 만드는 CI 단계의 용어들입니다.

CI (지속적 통합, Continuous Integration) 코드를 저장소에 올릴 때마다, 서버가 자동으로 빌드하고 테스트를 돌려주는 구조입니다. “내 컴퓨터에선 됐는데요"라는 말이 사라지는 게 핵심 효과예요. 사람이 매번 기억해서 검사를 돌릴 필요 없이, 올리는 순간 기계가 대신 확인해주니까요. 공항 보안검색대처럼, 모든 코드가 이 관문을 통과해야 다음 단계로 넘어갑니다. → 자세히: 17편 (연재 예정)

PR (Pull Request) “내가 만든 이 변경을 메인 코드에 합쳐주세요"라고 요청하는 단위입니다. 동료가 코드를 살펴보고(리뷰), CI 검사가 통과해야 비로소 합쳐지죠. 혼자 하는 프로젝트라도 PR을 쓰면 변경 이력이 깔끔하게 남고, 합치기 전에 자동 검사를 강제할 수 있어 유용합니다. → 자세히: 17편 (연재 예정)

머지 게이트 (merge gate) 정해진 검사를 모두 통과하기 전에는 코드를 합칠 수 없도록 막아두는 규칙입니다. 테스트가 실패하거나 접근성 검사가 걸리면 합치기 버튼이 잠기는 식이죠. 사람의 선의나 기억에 기대지 않고 품질 기준을 시스템으로 강제한다는 점에서, 팀 규모가 커질수록 특히 힘을 발휘합니다. 개찰구에 표를 넣어야 문이 열리는 것과 같아요. → 자세히: 17편 (연재 예정)

아티팩트 (artifact) CI가 한 번 실행되면서 남기는 산출물입니다. 테스트 리포트, 실패 시의 트레이스, 스크린샷, 커버리지 결과 같은 것들이죠. CI는 내 컴퓨터가 아닌 원격 서버에서 돌기 때문에, 무언가 실패했을 때 직접 들여다볼 수 없습니다. 그래서 이 아티팩트가 사고 현장의 증거물 역할을 하며, 원인 조사의 출발점이 됩니다. → 자세히: 17편 (연재 예정)

라인 커버리지 / 브랜치 커버리지 커버리지를 세는 두 가지 방식입니다. 라인 커버리지는 “실행된 코드 줄"의 비율이고, 브랜치 커버리지는 “조건 분기의 양쪽(if가 참일 때와 거짓일 때)을 모두 밟았는지"의 비율이에요. 한 줄을 지나갔다고 그 안의 모든 경우를 확인한 건 아니기 때문에, 보통 브랜치 커버리지가 더 정직한 숫자입니다. 빈 갈림길을 찾을 때 이 구분이 도움이 됩니다. → 자세히: 18편 (연재 예정)

AI 시대 (5장)

AI에게 테스트를 맡길 때 알아야 할 용어들입니다.

LLM (대형 언어 모델, Large Language Model) ChatGPT나 Claude처럼, 방대한 텍스트를 학습해 코드를 포함한 글을 생성하는 AI를 가리킵니다. 테스트 초안을 순식간에 만들어주는 든든한 조력자지만, 그럴듯해 보여도 실제로는 아무것도 검증하지 않는 코드를 내놓기도 합니다. 그래서 “빠른 초안"으로 활용하되, 사람이 반드시 검토하고 다듬는다는 전제가 필요해요. → 자세히: 19편 (연재 예정)

뮤테이션 체크 (mutation check) 테스트가 정말 제 역할을 하는지 되묻는 방법입니다. 원리는 간단해요. 코드 일부를 일부러 틀리게 바꿔본 뒤, 그때 테스트가 실패하는지를 봅니다. 코드를 망가뜨렸는데도 테스트가 초록불이라면, 그 테스트는 사실상 아무것도 지키지 못하고 있는 거예요. 화재경보기 앞에서 일부러 연기를 피워 제대로 울리는지 점검하는 것과 같습니다. AI가 만든 테스트를 믿어도 될지 가늠할 때 특히 유용해요. → 자세히: 19편 (연재 예정)

codegen 브라우저에서 직접 클릭하고 입력하는 동작을 그대로 따라 적어 테스트 코드로 만들어주는 Playwright 도구입니다. 처음부터 손으로 셀렉터를 쓰기 막막할 때 초안을 빠르게 얻는 데 좋아요. 다만 자동으로 뽑힌 코드는 셀렉터가 불안정하거나 불필요한 단계가 섞여 있을 수 있어서, 받아 적은 초안을 사람이 다듬어 쓰는 게 원칙입니다. → 자세히: 20편 (연재 예정)

MCP (Model Context Protocol) AI 에이전트가 브라우저 같은 외부 도구를 직접 다룰 수 있도록 이어주는 표준 규격입니다. 이 연결이 있으면 AI가 말로만 설명하는 데 그치지 않고, 실제로 페이지를 열고 버튼을 눌러보며 테스트를 시도할 수 있어요. AI의 손에 공구를 쥐여주는 표준 플러그라고 생각하면 됩니다. → 자세히: 20편 (연재 예정)

자가치유 셀렉터 (self-healing selector) 화면 구조가 바뀌어 셀렉터가 깨졌을 때, AI가 대체 후보를 찾아 알아서 고쳐주는 방식입니다. 사소한 변경 때문에 테스트가 무더기로 실패하는 일을 줄여주니 편리하죠. 다만 AI가 엉뚱한 요소를 새 대상으로 잡을 수도 있어서, 그 판단이 맞는지는 사람이 확인해야 합니다. 편리함과 검증을 맞바꾸지 않는 게 중요해요. → 자세히: 20편 (연재 예정)

마치며

이 페이지는 시리즈가 이어지는 동안 계속 다듬어집니다. “이 용어도 넣어주세요"나 “이 설명이 오히려 헷갈려요” 같은 의견이 있다면 댓글로 편하게 알려주세요.

본편으로 돌아가기: 1편 — 왜 지금 프론트엔드 테스트인가