F-3: 화면을 확인한다 — 글자가 없는 버튼을 어떻게 찾을까

안녕하세요, 홍순구입니다.

지난 시간 마지막에 질문을 하나 남겼죠. 버튼을 어떻게 찾을 것인가.

이유까지 붙였는데, 사용자는 우리 코드를 모른다고, 사용자는 "좋아요 라고 적힌 버튼"을 누른다고 했습니다.

오늘은 그 문장을 우리 앱에 그대로 들고 가봅니다. 그런데 시작하자마자 이상한 일이 생겨요.

우리 좋아요 버튼에는 글자가 하나도 없습니다.

하트 그림 하나뿐이라 "좋아요"라고 적혀 있지 않은데, 지난 시간에 제가 한 말이 틀린 걸까요, 아니면 우리 버튼이 잘못 만들어진 걸까요?

둘 다 아니고, 그 답을 찾는 과정이 오늘 배울 것의 전부예요.

오늘의 여정

  글자로 찾아봅니다      ──  render · screen, 그리고 두 번의 실패
  역할과 이름으로        ──  getByRole 과 접근성 이름
  찾았다고 어떻게 말하나  ──  jest-dom 매처
  다른 방법들과 그 순서   ──  네 가지 중 무엇을 먼저
  있어야 · 없어야 · 곧   ──  getBy · queryBy · findBy
  누릅니다              ──  userEvent
  댓글 폼을 사용자처럼    ──  입력하고 제출하기
  바꿔도 안 깨지는 판     ──  구현을 붙잡지 않는다

💡 오늘 수업의 핵심 — "판은 사용자가 인지하는 것을 붙잡는다. 화면이 어떻게 만들어졌는지가 아니라"

🎯 학습 목표

• render와 screen으로 컴포넌트를 그려놓고, 역할과 이름으로 원하는 요소를 찾을 수 있다.
• 네 가지 찾는 방법의 우선순위를 이해하고, getBy·queryBy·findBy를 상황에 맞게 고를 수 있다.
• userEvent로 사용자처럼 누르고 입력해서, 구현을 바꿔도 안 깨지는 판을 쓸 수 있다.

Step 1: "화면을 그려놓고 글자로 찾아봅니다"

지난 시간에 우리가 쓴 판을 떠올려보세요. toggleLikeInPlace에 배열을 넣고 배열을 받았고, fetchConversations에 주소를 물어 데이터를 받았습니다.

전부 화면이 없는 코드였고, 넣으면 나오는 것들이었죠.

그런데 우리 앱의 대부분은 화면입니다. 하트를 누르면 빨개지고, 댓글을 쓰면 목록에 붙어요. 이런 걸 확인하려면 먼저 화면을 그려놓아야 합니다.

그런데 브라우저가 없는데요

여기서 바로 걸립니다. 테스트는 터미널에서 도는데, 화면을 그리려면 브라우저가 필요하잖아요.

지난 시간에 우리가 열어본 설정 파일을 다시 보세요.

// apps/web-spa/vitest.config.ts
export default mergeConfig(
  viteConfig,
  defineConfig({
    test: {
      environment: 'jsdom',
      globals: true,
      setupFiles: ['./src/test-setup.ts'],

environment: 'jsdom'이 그 답입니다. jsdom은 자바스크립트로 만든 가짜 DOM이에요. 진짜 브라우저는 아니지만 document도 있고 <button>도 있고 클릭 이벤트도 받습니다. 이 위에 화면을 그리는 거예요.

그림도 안 뜨고 창도 안 열리지만, 대신 구조와 동작은 그대로 있어요. 우리가 확인하려는 게 그거니까 충분합니다.

그려봅시다

두 가지만 새로 들여옵니다.

import { render, screen } from '@testing-library/react';

render는 컴포넌트를 jsdom 위에 그립니다. screen은 그려진 화면 전체를 가리키는 손잡이예요. 화면에서 무언가를 찾을 때는 screen에게 묻습니다.

이제 지난 시간에 남긴 문장대로 해봅시다. 사용자는 "좋아요 라고 적힌 버튼"을 누른다고 했으니까요.

// apps/web-spa/src/components/f3-like-button.test.tsx
render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

screen.getByText('좋아요');

돌려보면 이렇게 나옵니다.

Unable to find an element with the text: 좋아요. This could be because the
text is broken up by multiple elements. In this case, you can provide a
function for your text matcher to make your matcher more flexible.

못 찾았어요. 왜일까요?

버튼 안을 열어보면

LikeButton을 열어보면 이유가 바로 보입니다.

// apps/web-spa/src/components/LikeButton.tsx
<IconButton
  className="cursor-pointer p-2 transition duration-150 ..."
  aria-label="좋아요"
  aria-pressed={liked}
  onClick={onToggle}
>
  <Heart className={...} />
</IconButton>

버튼 안에 들어 있는 것은 <Heart /> 하나뿐이라, 하트 그림이지 글자가 아니에요.

실제로 버튼의 textContent를 찍어보면 빈 문자열이 나옵니다. 읽어 낼 글자가 하나도 없어요.

E-6에서 이 버튼은 원래 ♡ 좋아요라고 적힌 글자 버튼이었는데, E-7에서 인스타그램처럼 하트 아이콘으로 바꾸면서 글자가 사라졌어요.

더 위험한 두 번째 시도

자, 그러면 화면에 보이는 글자로 찾아보면 어떨까요. 개수 줄에는 "좋아요 1240개"라고 적혀 있으니까요.

const found = screen.getByText('좋아요 1240개');

이번엔 찾아지는데, 판이 초록으로 통과해요.

그런데 찾아진 게 뭔지 확인해보면 이렇습니다.

found.tagName  →  'P'

버튼이 아니라 개수를 적어둔 문단이라서, 이걸 눌러도 좋아요가 눌리지 않습니다.

  첫 번째 시도            두 번째 시도
  ─────────────────      ─────────────────
  못 찾는다               찾아진다
  판이 빨개진다            판이 초록이다
  바로 알아챈다            아무도 안 알려준다

앞의 것보다 뒤의 것이 훨씬 위험합니다. 실패는 즉시 보이지만, 엉뚱한 것을 잡은 채 통과하는 판은 계속 초록으로 남아 있어요. 그러다 어느 날 개수 줄의 문구가 바뀌면 그때야 빨개지고 우리는 엉뚱한 곳을 들여다보게 되니까, 지난 시간 문장을 고쳐야 합니다. 사용자가 누르는 것은 "좋아요 라고 적힌" 버튼이 아니에요. "좋아요 라는 뜻으로 읽히는" 버튼입니다. 눈으로 보는 사람에게는 하트 모양이 그 뜻이고, 화면을 못 보는 사람에게는 낭독기가 읽어주는 이름이 그 뜻이죠.

그 "읽히는 이름"을 찾는 방법이 다음 단계입니다.

💡 한 줄 정리

render로 jsdom 위에 화면을 그리고 screen으로 찾는데, 눈에 보이는 글자로 찾으면 안 되는 경우가 있다. 우리 좋아요 버튼처럼 글자가 없는 버튼이 그렇고, 더 나쁜 것은 비슷한 글자를 가진 엉뚱한 요소가 조용히 잡히는 것이다.

Step 2: "역할과 이름으로 찾습니다"

버튼을 찾는 올바른 방법은 이겁니다.

// apps/web-spa/src/components/f3-like-button.test.tsx
const button = screen.getByRole('button', { name: '좋아요' });

두 조각으로 되어 있어요. 역할(role)과 이름(name)입니다.

역할이란

역할은 그 요소가 화면에서 무엇 노릇을 하는가입니다. <button>은 button 역할, <input type="text">는 textbox 역할, <h1>은 heading 역할이에요.

중요한 건 이게 우리가 붙이는 게 아니라 태그를 쓰면 자동으로 정해진다는 겁니다. <button>을 쓰면 그냥 button 역할이 돼요.

낭독기가 화면을 읽을 때 쓰는 게 바로 이 역할입니다. "버튼, 좋아요" 하고 읽어주죠. 우리가 판에서 getByRole('button', { name: '좋아요' })라고 쓰는 것은 낭독기가 읽는 방식 그대로 찾는 것이에요.

이름은 어디서 오나

button 역할을 가진 요소는 이 화면에 여럿일 수 있으니, 어느 것인지 이름으로 좁히는데, 우리 버튼에는 글자가 없다고 했으니 이름이 어디서 올까요?

LikeButton에 있던 이 한 줄입니다.

aria-label="좋아요"

aria-label은 눈에는 안 보이지만 낭독기에는 읽히는 이름을 붙이는 속성이에요. 글자가 없는 버튼에 이름을 주는 표준 방법입니다.

이렇게 정해지는 이름을 접근성 이름(accessible name)이라고 불러요. 글자가 있는 버튼은 그 글자가 접근성 이름이 되고, 글자가 없으면 aria-label이 대신합니다.

첫 판을 씁니다

판을 하나 만들어봅시다.

// apps/web-spa/src/components/f3-like-button.test.tsx
import { describe, it, expect } from 'vitest';
import { render, screen } from '@testing-library/react';
import { LikeButton } from './LikeButton';

describe('좋아요 버튼', () => {
  it('역할과 이름으로 찾을 수 있다', () => {
    render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

    const button = screen.getByRole('button', { name: '좋아요' });

    expect(button.tagName).toBe('BUTTON');
  });

  it('그 이름은 눈에 보이는 글자가 아니다', () => {
    render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

    const button = screen.getByRole('button', { name: '좋아요' });

    // 버튼 안에는 하트 그림뿐이라 읽어 낼 글자가 없다
    expect(button.textContent).toBe('');
  });
});

두 번째 판이 재밌습니다. 이름으로 찾았는데 그 이름이 글자로는 없다는 것을 확인하고 있어요. Step 1에서 본 것을 그대로 판에 적어둔 겁니다.

이름을 빼먹을 수는 없나

여기서 재밌는 걸 하나 확인해봅시다. LikeButton에서 aria-label 한 줄을 지우면 어떻게 될까요?

판은 물론 깨지는데, 판보다 먼저 막히는 게 있어요.

error TS2741: Property ''aria-label'' is missing in type
  '{ children: Element; className: string; "aria-pressed": boolean; onClick: () => void; }'
  but required in type '{ 'aria-label': string; }'

타입 검사가 막습니다. A-4에서 만든 IconButton을 열어보면 이유가 보여요.

// apps/web-spa/src/components/IconButton.tsx
type IconButtonProps = ComponentProps<typeof Button> & {
  'aria-label': string;
};

A-4에서 우리는 이 타입을 만들면서 이렇게 적어뒀습니다. "글자 대신 기호만 보이는 버튼이라, 읽어줄 이름은 있으면 좋은 게 아니라 필수다."

그때는 접근성을 위한 결정이었는데, 오늘 그 결정이 한 번 더 값을 합니다. getByRole('button', { name })이 통한다는 것이 타입 수준에서 보장되어 있는 거예요. 아이콘 버튼을 새로 만드는 사람은 이름을 빼먹을 수가 없습니다.

화면 전체의 역할을 한눈에

버튼 하나 말고 카드 전체는 어떻게 생겼을까요. RTL에는 화면의 역할을 통째로 찍어주는 도구가 있습니다.

import { logRoles } from '@testing-library/react';

const { container } = render(<PostCard {...feedPosts[0]} onToggleLike={() => {}} />);
logRoles(container);

PostCard 하나를 그려놓고 찍으면 이렇게 나옵니다.

article    Name ""
img        Name "jaehoon 프로필 사진"
           Name "jaehoon 의 게시물"
button     Name "게시물 메뉴"
           Name "좋아요"
           Name "더 보기"
           Name "댓글 32개 모두 보기"
           Name "게시"
paragraph  Name "" x3
list       Name ""
textbox    Name "댓글 입력"

이게 낭독기가 보는 우리 카드입니다. 버튼이 다섯 개 있고 전부 이름이 달라서, 이름만으로 다섯을 전부 구분할 수 있습니다.

맨 위의 article도 반가운 자국이에요. E-6에서 들여온 카드가 <div>였는데 "여기부터 하나의 글"이라는 뜻이 사라진다고 해서 <article>로 되돌렸죠. 그 결정이 여기 그대로 남아 있습니다.

💡 한 줄 정리

getByRole(역할, { name })은 낭독기가 화면을 읽는 방식 그대로 요소를 찾는다. 역할은 태그가 정하고, 이름은 글자나 aria-label이 정한다. logRoles로 화면 전체의 역할 목록을 볼 수 있다.

Step 3: "찾았다는 것을 어떻게 말하나"

찾는 방법은 알았는데, 찾은 다음에 무엇을 확인해야 할까요?

Step 2의 판에서는 expect(button.tagName).toBe('BUTTON')이라고 썼습니다. 지난 시간에 배운 expect와 toBe 그대로인데, 화면을 확인할 때는 훨씬 편한 방법이 있습니다.

매처가 이미 깔려 있었습니다

지난 시간에 설정 파일에서 본 setupFiles 기억나세요? 그 파일 첫 줄이 이겁니다.

// apps/web-spa/src/test-setup.ts
import '@testing-library/jest-dom/vitest';

이 한 줄이 화면 전용 매처 수십 개를 expect에 붙여줍니다. 우리가 A-1부터 계속 쓰고 있었는데 오늘에서야 이름을 부르는 거예요.

몇 개만 보면 이렇습니다.

expect(button).toBeInTheDocument();          // 화면에 있는가
expect(button).toBeDisabled();               // 잠겨 있는가
expect(button).toHaveAccessibleName('좋아요'); // 읽히는 이름이 이건가
expect(button).toHaveAttribute('aria-pressed', 'true');
expect(input).toHaveValue('');               // 입력칸이 비었는가

그냥 expect로도 되는데 왜

toBeDisabled() 대신 expect(button.disabled).toBe(true)라고 써도 확인은 됩니다. 그러면 왜 매처를 쓸까요?

틀렸을 때 알려주는 양이 다릅니다. 같은 상황에서 두 방식의 실패 메시지를 나란히 놓아볼게요.

toBeDisabled()          expect(element).toBeDisabled()
                        Received element is not disabled:
                        <button aria-label="좋아요" aria-pressed="false" ...>

.disabled toBe(true)    expected false to be true

아래쪽은 false가 나왔다는 것만 알려줍니다. 어느 요소인지, 그 요소가 지금 어떤 상태인지는 안 알려줘요. 위쪽은 문제의 요소를 통째로 찍어줍니다.

판은 통과할 때보다 깨질 때 일을 합니다. 깨진 판 앞에서 원인을 얼마나 빨리 찾느냐가 매처를 고르는 이유예요.

판을 두 개 더 씁니다

// apps/web-spa/src/components/f3-like-button.test.tsx
it('그래도 낭독기에는 이름이 있다', () => {
  render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

  // 이름을 조건에 넣지 않고 찾은 다음, 그 이름이 무엇인지를 확인한다
  expect(screen.getByRole('button')).toHaveAccessibleName('좋아요');
});

it('눌렸다는 것은 이름이 아니라 눌림 표시로 드러난다', () => {
  render(<LikeButton liked={true} likeCount={1241} onToggle={() => {}} />);

  const button = screen.getByRole('button', { name: '좋아요' });

  expect(button).toBeInTheDocument();
  expect(button).toHaveAttribute('aria-pressed', 'true');
});

첫 번째 판에 요령이 하나 있습니다. getByRole('button')으로 이름 없이 찾고 나서 이름을 확인해요. 이름을 조건에 넣어놓고 그 이름이 맞는지 확인하면 당연한 소리가 되니까요.

두 번째 판은 E-7의 결정을 지킵니다. 하트 버튼은 눌러도 이름이 안 바뀌고 계속 "좋아요"인데, 눌렸는지는 aria-pressed가 알립니다. 눈으로 보는 사람에게는 하트 속이 빨갛게 차는 것으로 알리고요.

💡 한 줄 정리

setupFiles의 한 줄이 화면 전용 매처를 깔아둔다. 매처는 편해서가 아니라 깨졌을 때 문제의 요소를 통째로 찍어주기 때문에 쓴다.

expect(screen.queryByText(/좋아요 \d+개/)).not.toBeInTheDocument();

Step 4: "다른 방법들과 그 순서"

지금까지 두 가지 방법을 봤습니다. 글자로 찾기와 역할로 찾기요. 사실 방법은 더 있어요.

같은 좋아요 버튼을 이렇게도 찾을 수 있습니다.

screen.getByLabelText('좋아요');

이건 getByRole('button', { name: '좋아요' })와 완전히 같은 요소를 돌려주는데, 둘을 ===로 비교해보면 참이에요. 둘 다 aria-label을 읽으니까요.

그러면 어느 걸 써야 할까요? 여기서 우선순위가 나옵니다.

네 가지와 그 순서

  1. getByRole        역할 + 이름          ← 먼저 이걸 시도한다
  2. getByLabelText   이름표가 붙은 입력칸
  3. getByText        눈에 보이는 글자
  4. getByTestId      우리가 심어둔 표시    ← 마지막 수단

순서의 기준은 하나입니다. 사용자에게 가까운 순서예요.

getByRole이 첫째인 이유는 그게 낭독기가 실제로 화면을 읽는 방식이기 때문입니다. 역할과 이름은 사용자에게 도달하는 정보고, 우리가 판에서 그걸 그대로 쓰면 판이 사용자와 같은 것을 본다는 뜻이에요.

getByLabelText는 입력칸에서 특히 좋습니다. 사람이 폼을 채울 때 "이름"이라고 적힌 칸을 찾아 쓰잖아요. 그 이름표를 그대로 쓰는 겁니다.

getByText는 글자 그대로 찾습니다. Step 1에서 봤듯 역할을 안 보기 때문에 문단이든 버튼이든 글자만 맞으면 잡혀요. 그래서 셋째입니다.

마지막 수단이 마지막인 이유

getByTestId는 이렇게 씁니다. 컴포넌트에 표시를 심어두고 그걸로 찾는 거예요.

<p data-testid="count">좋아요 {likeCount}개</p>

screen.getByTestId('count');

확실하게 찾힙니다. 안 헷갈려요. 그런데 사용자는 data-testid를 볼 수 없습니다. 화면에도 안 나오고 낭독기도 안 읽어요. 오직 판을 위해서만 존재하는 표시라서, 이걸로 찾는 판은 사용자가 아니라 우리가 심어둔 것을 보고 있는 거예요.

우리 저장소는 어떻게 쓰고 있었나

말로만 하면 규칙처럼 들리니까 저장소를 직접 세어봅시다.

  getByRole          369
  getByText          177
  getByLabelText     122
  getByTestId         12

우선순위 그대로인데, 재밌는 건 마지막 줄이에요.

getByTestId 12건이 어디 있는지 하나씩 열어보면, 전부 판이 직접 그렸거나 확인용으로 따로 둔 화면에 붙어 있습니다. 앱 코드에는 data-testid가 하나도 없어요.

// apps/web-spa/src/components/b4-answer.test.tsx — 판이 자기 화면을 직접 그린다
<p data-testid="count">좋아요 {likedCount}개</p>
<button onClick={() => toggle(posts[0].id)}>토글</button>

붙어 있는 것들은 전부 <p>인데, 아까 Step 2에서 <div> 나 <span>은 역할이 없다고 했죠. <p>도 이름을 가질 수 없어서, 역할로는 원리적으로 못 찾는 것들입니다.

이게 정당한 예외의 모양이에요. "역할로 못 찾는 것을 셀 때만 쓴다"이고, 그마저도 앱이 아니라 판이 만든 화면에서만 씁니다.

그럼 우리는 어떻게 골라야 하나

간단합니다. 위에서부터 내려오면 돼요.

  역할로 찾히나?          →  된다  →  getByRole
        ↓ 안 된다
  이름표가 붙어 있나?      →  된다  →  getByLabelText
        ↓ 안 된다
  고유한 글자가 있나?      →  된다  →  getByText
        ↓ 안 된다
  왜 못 찾는지 먼저 생각해본다

마지막 줄이 핵심이에요. 역할로도 이름으로도 글자로도 못 찾는다면, 그건 판의 문제가 아니라 화면의 문제일 가능성이 큽니다. 사용자도 그걸 못 찾고 있을지 몰라요. data-testid를 붙이기 전에 그 질문을 먼저 해야 합니다.

💡 한 줄 정리

찾는 방법의 순서는 사용자에게 가까운 순서다. 우리 저장소도 369 / 177 / 122 / 12로 정확히 그 순서로 쓰고 있고, 마지막 12건은 전부 역할이 없는 요소를 판이 직접 그린 경우다.

Step 5: "있어야 · 없어야 · 곧 올 것"

지금까지 쓴 것은 전부 getBy로 시작했는데, 앞에 붙는 말이 세 가지예요.

  getBy    있어야 한다        없으면 던진다
  queryBy  없을 수도 있다      없으면 null 을 준다
  findBy   지금은 없고 곧 온다  올 때까지 기다린다

셋은 찾는 방법이 아니라 못 찾았을 때 어떻게 할지가 다릅니다. getByRole·queryByRole·findByRole은 전부 역할로 찾아요.

없어야 하는 것을 확인할 때

getBy는 못 찾으면 던집니다. 이렇게요.

Unable to find an accessible element with the role "button" and name "없는버튼"

그래서 없다는 것을 확인하는 데는 못 씁니다. 없으면 판이 그 자리에서 죽어버리니까요.

그럴 때 queryBy를 씁니다. 못 찾으면 null을 돌려줘요.

우리 앱에 딱 맞는 자리가 있습니다. LikeButton을 다시 보세요.

// apps/web-spa/src/components/LikeButton.tsx
{likeCount > 0 && <p className="px-2 pt-1 pb-1 text-sm font-semibold">좋아요 {likeCount}개</p>}

좋아요가 0개면 개수 줄 자체가 안 그려집니다. "좋아요 0개"라고 쓰는 게 아니라 아예 없어요.

이건 확인할 값어치가 있는 동작입니다. 판으로 적어둡시다.

// apps/web-spa/src/components/f3-like-button.test.tsx
it('좋아요가 0개면 개수 줄이 아예 없다', () => {
  render(<LikeButton liked={false} likeCount={0} onToggle={() => {}} />);

  // 없어야 하는 것을 확인할 때는 queryBy 로 묻는다 — getBy 는 여기서 던진다
  expect(screen.queryByText(/좋아요 \d+개/)).not.toBeInTheDocument();
});

Step 3에서 예고한 대로, 여기서 toBeInTheDocument가 확실히 일을 합니다.

여럿이 잡힐 때

getBy에는 반대 방향의 함정도 있습니다. 둘 이상 찾히면 그것도 던져요.

피드에는 카드가 여러 장이니 하트도 여러 개죠. 그 상황을 만들어보면 이렇게 나옵니다.

Found multiple elements with the role "button" and name "좋아요"

이럴 때는 getAllBy로 전부 받는데, 우리 버튼에는 갈라 볼 방법이 하나 더 있어요.

it('하트가 여럿이면 눌림 여부로 가른다', () => {
  render(
    <>
      <LikeButton liked={false} likeCount={10} onToggle={() => {}} />
      <LikeButton liked={true} likeCount={20} onToggle={() => {}} />
    </>,
  );

  expect(screen.getAllByRole('button', { name: '좋아요' })).toHaveLength(2);
  expect(screen.getAllByRole('button', { name: '좋아요', pressed: true })).toHaveLength(1);
});

{ pressed: true }를 보세요. 이건 Step 3에서 본 aria-pressed를 조건으로 쓰는 겁니다. 이름이 같은 버튼들을 상태로 갈라내는 거예요.

이름·역할·상태가 전부 사용자에게 도달하는 정보라는 게 여기서 다시 보입니다. 우리는 사용자가 구분할 수 있는 방식으로만 구분하고 있어요.

곧 오는 것을 기다릴 때

세 번째 findBy는 기다립니다. 지금은 화면에 없지만 곧 나타날 것을 찾을 때 써요.

우리 저장소에 이미 쓰고 있는 곳이 있습니다. 피드는 서버에서 오니까 처음엔 카드가 없죠.

// apps/web-spa/src/queries/c6-optimistic.test.tsx (읽기만 합니다)
const hearts = await screen.findAllByRole('button', { name: '좋아요' });

await가 붙어 있는 게 보이시죠. 데이터가 도착해서 하트가 그려질 때까지 기다렸다가 잡는 겁니다. 못 찾은 채 시간이 지나면 그때 던져요.

오늘 우리가 직접 쓰는 판은 전부 화면이 즉시 완성되는 것들이라 findBy를 쓸 자리가 없습니다. 서버가 끼는 화면을 제대로 확인하는 건 다음 시간에 도구를 하나 더 갖춘 다음에 할게요.

💡 한 줄 정리

getBy·queryBy·findBy는 못 찾았을 때의 태도가 다르다. 없어야 하는 것은 queryBy, 곧 올 것은 findBy, 나머지는 getBy 다. 여럿이면 getAllBy로 받고 상태로 가른다.

const button = screen.queryByRole('button', { name: '좋아요' });
expect(button).toBeInTheDocument();

const button = screen.queryByRole('button', { name: '좋아요' });
// 확인 없이 그냥 쓴다

Step 6: "누릅니다"

찾았으니 이제 눌러볼 차례예요.

import userEvent from '@testing-library/user-event';

await userEvent.click(screen.getByRole('button', { name: '좋아요' }));

user-event는 RTL과 짝을 이루는 도구입니다. 이름 그대로 사용자가 하는 일을 흉내 내요. 클릭, 타이핑, 탭 이동 같은 것들이죠.

판을 씁니다

지난 시간에 배운 vi.fn()을 여기서 다시 씁니다. 버튼이 정말 알려주는지 확인해야 하니까요.

// apps/web-spa/src/components/f3-like-button.test.tsx
it('누르면 알려준다', async () => {
  const onToggle = vi.fn();
  render(<LikeButton liked={false} likeCount={1240} onToggle={onToggle} />);

  await userEvent.click(screen.getByRole('button', { name: '좋아요' }));

  expect(onToggle).toHaveBeenCalledTimes(1);
});

it('눌러도 스스로 숫자를 바꾸지는 않는다', async () => {
  render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

  await userEvent.click(screen.getByRole('button', { name: '좋아요' }));

  // 이 버튼은 받은 것을 그릴 뿐이다. 숫자를 바꾸는 쪽은 위에 있다.
  expect(screen.getByText('좋아요 1240개')).toBeInTheDocument();
  expect(screen.getByRole('button', { name: '좋아요' })).toHaveAttribute('aria-pressed', 'false');
});

두 번째 판을 눈여겨보세요. 눌렀는데 아무것도 안 바뀌는 것을 확인하고 있습니다.

이상해 보이지만 맞는 판이에요. LikeButton은 liked와 likeCount를 받아서 그리기만 할 뿐 상태를 안 들고 있는데, B-2에서 상태를 위로 끌어올린 결과죠. 누르면 위에 알리고, 숫자를 바꾸는 것은 위의 몫입니다.

이 판은 그 설계가 유지되는지를 지킵니다. 누군가 LikeButton 안에 useState를 넣는 순간 빨개져요.

await를 빼면

userEvent 앞에 붙은 await가 눈에 걸리셨을 겁니다. 클릭 한 번 하는데 왜 기다릴까요?

빼보면 압니다.

await 전 호출 횟수  →  0
await 후 호출 횟수  →  1

await를 빼면 클릭이 아예 안 일어납니다. 판은 그다음 줄로 넘어가고, onToggle은 안 불린 상태예요.

userEvent가 사용자를 제대로 흉내 내려고 여러 단계를 밟기 때문입니다. 사람이 버튼을 누를 때도 마우스가 위로 오고, 눌리고, 떼어지죠. 그 단계들이 순서대로 처리되기를 기다려야 해요.

그래서 규칙은 단순합니다. userEvent는 항상 await를 붙인다.

fireEvent는 뭔가요

검색하다 보면 fireEvent라는 것도 나옵니다. 이것도 클릭을 일으켜요.

fireEvent.click(button);   // await 가 없다

우리 하트 버튼에서는 결과가 같아서 둘 다 onToggle을 한 번 부르지만, 입력칸에서 갈립니다.

같은 abc를 넣는데 onChange가 불리는 횟수가 이렇게 달라요.

  userEvent.type(input, 'abc')                onChange 3회   "a" → "ab" → "abc"
  fireEvent.change(input, { value: 'abc' })   onChange 1회   "abc"

userEvent는 사람이 하는 대로 한 글자씩 치고, fireEvent는 값을 통째로 바꿔 끼웁니다.

이 차이가 중요한 이유는, 한 글자씩 칠 때만 드러나는 버그가 있기 때문이에요. 두 글자까지는 괜찮은데 세 글자째에 뭔가 잘못되는 코드가 있다면 fireEvent로는 영영 못 잡습니다.

우리 저장소는 무엇을 쓰고 있나

세어보면 답이 명확합니다.

  user-event 를 쓰는 파일    75개
  fireEvent 를 쓰는 파일      1개  (3건)

그 1개는 C-8에서 렌더 횟수를 세던 판이에요. 거기엔 fireEvent를 써야 하는 특별한 이유가 있었고 그 이유가 파일에 적혀 있습니다.

75 대 1입니다. 기본은 userEvent이고, fireEvent는 이유를 댈 수 있을 때만 쓰는 예외예요.

💡 한 줄 정리

userEvent는 사용자가 하는 일을 흉내 낸다. 항상 await를 붙인다 — 빼면 아무 일도 안 일어난다. fireEvent는 값을 통째로 바꿔 끼우기 때문에 한 글자씩 칠 때만 드러나는 문제를 놓친다.

Step 7: "댓글 폼을 사용자처럼 씁니다"

버튼은 눌러봤으니 이번엔 글자를 넣어봅시다. 댓글 폼이 좋은 대상이에요. 입력칸과 버튼이 함께 있고, 둘이 서로 반응하거든요.

먼저 폼을 열어봅시다.

// apps/web-spa/src/components/CommentForm.tsx
<form className="..." onSubmit={handleSubmit}>
  <CommentInput ref={inputRef} value={content} onChange={handleChange} />
  <Button type="submit" disabled={isEmpty} ...>
    게시
  </Button>
</form>

빈칸이면 게시 버튼이 잠기는데, B-5에서 만든 동작이죠.

폼은 어떻게 찾나

여기서 함정을 하나 만납니다. <form> 자체를 찾으려고 하면 안 찾아져요.

screen.queryByRole('form');   //  null

<form>은 이름이 없으면 역할도 없습니다. 조금 이상하게 들리지만 규칙이 그런데, 사실 찾을 필요는 없습니다. 사용자도 폼이라는 상자를 인식하지 않고, 사용자가 보는 것은 입력칸과 버튼이라 그것들로 찾으면 됩니다.

screen.getByLabelText('댓글 입력');            // 입력칸
screen.getByRole('button', { name: '게시' });  // 버튼

입력칸에 getByLabelText를 쓴 게 Step 4의 우선순위 그대로예요. CommentInput에 aria-label="댓글 입력"이 붙어 있습니다.

사용자가 하는 순서대로

판을 씁니다. 사람이 댓글을 다는 순서를 그대로 따라가요.

// apps/web-spa/src/components/f3-comment-form.test.tsx
import { describe, it, expect, vi } from 'vitest';
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { CommentForm } from './CommentForm';

describe('댓글 폼', () => {
  it('빈칸이면 게시 버튼이 잠겨 있다', () => {
    render(<CommentForm onSubmit={() => {}} />);

    expect(screen.getByRole('button', { name: '게시' })).toBeDisabled();
  });

  it('글자를 넣으면 풀린다', async () => {
    render(<CommentForm onSubmit={() => {}} />);

    await userEvent.type(screen.getByLabelText('댓글 입력'), '노을 예쁘네요');

    expect(screen.getByRole('button', { name: '게시' })).toBeEnabled();
  });

  it('게시하면 내용이 넘어가고 입력칸이 비워진다', async () => {
    const onSubmit = vi.fn();
    render(<CommentForm onSubmit={onSubmit} />);

    await userEvent.type(screen.getByLabelText('댓글 입력'), '노을 예쁘네요');
    await userEvent.click(screen.getByRole('button', { name: '게시' }));

    expect(onSubmit).toHaveBeenCalledWith('노을 예쁘네요');
    expect(screen.getByLabelText('댓글 입력')).toHaveValue('');
  });
});

세 번째 판이 두 가지를 한 번에 확인합니다. 내용이 제대로 넘어갔는지, 그리고 입력칸이 비워졌는지요.

두 번째 것을 빠뜨리기 쉬운데 사용자에게는 꽤 중요합니다. 댓글을 달았는데 입력칸에 방금 쓴 글이 그대로 남아 있으면, 실수로 한 번 더 보내게 되거든요.

사용자처럼 해야만 나오는 것 둘

여기까지는 예상 가능한 판입니다. 그런데 사용자를 제대로 흉내 내니까 생각 못 한 두 가지가 나왔어요.

첫째, 공백만 넣으면 어떻게 될까요?

it('공백만 넣으면 잠긴 채로 있다', async () => {
  render(<CommentForm onSubmit={() => {}} />);

  await userEvent.type(screen.getByLabelText('댓글 입력'), '   ');

  expect(screen.getByRole('button', { name: '게시' })).toBeDisabled();
});

잠긴 채로 있습니다. 스페이스 세 번은 글자를 넣은 게 아니라고 보는 거예요. useCommentInput을 열어보면 이유가 있습니다.

// apps/web-spa/src/hooks/useCommentInput.ts
const isEmpty = content.trim() === '';

B-5에서 넣어둔 trim() 한 번이 이 동작을 만듭니다. 그때는 그냥 지나갔을 텐데, 오늘 판으로 적어두면 누가 나중에 이 줄을 지웠을 때 알려줄 수 있어요.

둘째, 엔터를 치면요?

it('엔터로도 게시된다', async () => {
  const onSubmit = vi.fn();
  render(<CommentForm onSubmit={onSubmit} />);

  await userEvent.type(screen.getByLabelText('댓글 입력'), '노을 예쁘네요{enter}');

  expect(onSubmit).toHaveBeenCalledWith('노을 예쁘네요');
});

됩니다. 버튼을 안 눌렀는데 게시돼요.

{enter}라는 표기가 보이시죠. userEvent.type은 중괄호로 특수 키를 표현합니다. 사람이 글을 치다가 엔터를 누르는 것 그대로예요.

이게 되는 이유는 우리가 <form> 안에 type="submit" 버튼을 뒀기 때문인데, 브라우저가 원래 그렇게 동작해요. 우리가 만든 게 아니라 폼을 제대로 썼더니 딸려온 것입니다.

만약 <form> 없이 <div> 안에 버튼만 뒀다면 엔터는 아무 일도 안 했을 텐데, 그때는 키보드로만 쓰는 사람이 매번 탭을 눌러 버튼까지 이동해야 합니다.

클릭만 확인하는 판이었다면 이 사실을 영영 몰랐을 거예요. 사용자처럼 해봤기 때문에 나온 겁니다.

💡 한 줄 정리

폼은 상자가 아니라 안에 있는 입력칸과 버튼으로 찾는다. 사용자가 하는 순서대로 따라가면 공백만 넣었을 때나 엔터를 쳤을 때처럼 클릭만 확인해서는 안 나오는 동작이 드러난다.

Step 8: "바꿔도 안 깨지는 판"

오늘 우리는 판을 열세 개 썼는데, 이 판들이 정말 좋은 판인지 어떻게 알까요?

지난 시간 마지막에 이런 질문을 했었죠. "어떻게 만들었는지"를 판에 박으면 안 된다고 했고, 화면에서는 그게 훨씬 크게 문제가 된다고 예고했습니다.

오늘 그걸 실제로 재봅시다.

나쁜 판을 일부러 만들어봅니다

비교하려면 대조군이 필요합니다. 일부러 구현을 붙잡는 판을 세 개 써볼게요.

// 일부러 나쁘게 쓴 판입니다. 저장소에 두지 않아요.
it('안쪽 여백 클래스로 버튼을 찾는다', () => {
  const { container } = render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

  expect(container.querySelector('button.p-2')).not.toBeNull();
});

it('바깥이 div 이고 그 안에 button 과 p 가 순서대로 있다', () => {
  const { container } = render(<LikeButton liked={false} likeCount={1240} onToggle={() => {}} />);

  const root = container.firstElementChild;
  expect(root?.tagName).toBe('DIV');
  expect(root?.children[0].tagName).toBe('BUTTON');
  expect(root?.children[1].tagName).toBe('P');
});

셋 다 클래스도 맞고 구조도 맞으니까 지금은 통과합니다.

겉보기에는 나쁘지 않아 보이죠. "버튼이 있는지 확인한다"는 목적도 같고요.

구현을 다섯 가지로 바꿔봅니다

개발자가 실제로 할 법한 변경을 하나씩 해보고, 양쪽 판이 어떻게 되는지 봅시다.

  M1  클래스 이름을 바꾼다        p-2  →  px-2 py-2   (보이는 결과는 같다)
  M2  IconButton 을 안 쓰고 button 을 직접 쓴다
  M3  하트를 별 모양으로 바꾼다
  M4  바깥 div 를 span 으로 바꾼다
  M5  이름을 바꾼다              좋아요  →  하트

결과입니다.

  구현 변경                      우리 판 (8건)      구현 붙잡는 판 (3건)
  ─────────────────────────────────────────────────────────────────
  변경 없음                      8 통과             3 통과
  M1  클래스 이름 교체            8 통과             1 실패
  M2  IconButton 안 씀           8 통과             3 통과
  M3  하트 → 별                  8 통과             1 실패
  M4  div → span                8 통과             1 실패
  M5  이름 좋아요 → 하트          7 실패            3 통과

마지막 줄이 전부를 말합니다

위쪽 세 줄부터 보면, M1, M3, M4에서 우리 판은 조용하고 구현을 붙잡는 판만 우는데, M1과 M4에서 사용자에게 일어난 일은 아무것도 없습니다. 여백을 같은 값으로 다르게 적고 상자 태그를 바꿨을 뿐, 화면도 동작도 그대로입니다.

그런데 판이 빨개졌어요. 이건 거짓 경보입니다. 개발자는 멀쩡한 변경을 해놓고 판을 고치느라 시간을 씁니다. 이런 일이 반복되면 사람들은 판을 안 믿게 되고, 빨간 판을 보고도 "또 그거겠지" 하며 넘기게 돼요.

마지막 줄을 보세요.

M5는 사용자가 실제로 알아채는 유일한 변경입니다. 낭독기가 "버튼, 좋아요"라고 읽던 것을 "버튼, 하트"라고 읽게 돼요. 화면을 못 보는 사람에게는 이 버튼이 무슨 버튼인지가 바뀐 것인데, 구현을 붙잡는 판 셋은 전부 초록입니다. 클래스도 그대로고 구조도 그대로니까요. 아무도 안 알려줘요.

우리 판은 8건 중 7건이 빨개집니다.

  사용자에게 아무 일도 안 일어난 변경   →  우리 판 조용,  구현 판 운다
  사용자가 알아채는 변경              →  우리 판 운다,  구현 판 조용

정확히 반대로 동작하고 있어요. 이게 오늘 배운 것의 값입니다.

살아남은 한 건

M5에서 우리 판 8건 중 하나는 통과했습니다. 어느 것일까요?

  ×  역할과 이름으로 찾을 수 있다
  ×  그 이름은 눈에 보이는 글자가 아니다
  ×  그래도 낭독기에는 이름이 있다
  ×  눌렸다는 것은 이름이 아니라 눌림 표시로 드러난다
  ✓  좋아요가 0개면 개수 줄이 아예 없다
  ×  하트가 여럿이면 눌림 여부로 가른다
  ×  누르면 알려준다
  ×  눌러도 스스로 숫자를 바꾸지는 않는다

버튼을 이름으로 부르지 않는 유일한 판입니다. 개수 줄만 보고 있어서 버튼 이름이 바뀌든 말든 상관이 없어요.

이건 결함이 아니에요. 그 판은 다른 사실을 지키고 있는데, 판이 무엇을 붙잡고 있으면 무엇이 바뀔 때 우는지가 이렇게 정확히 대응한다는 게 잘 보이는 자리예요.

그런데 M3는 좀 걸리지 않나요

하트를 별로 바꿨는데 우리 판이 조용한 게 마음에 걸릴 수 있습니다. 사용자 눈에는 분명히 달라 보이잖아요.

맞습니다. 그리고 이건 경계예요.

RTL이 지키는 것은 무엇을 뜻하고 무엇을 하는가입니다. 별 모양이 됐어도 그 버튼은 여전히 "좋아요"라는 이름을 갖고, 누르면 여전히 좋아요가 눌려요. 뜻과 동작은 안 바뀌었습니다.

어떻게 보이는가는 다른 종류의 도구가 봅니다. 화면을 그림으로 찍어두고 달라진 곳을 찾아내는 방식인데, 그건 나중에 따로 다룹니다. 오늘 배운 판이 화면의 모든 것을 지켜주지는 않는 셈이라, 판이 안 지키는 것이 무엇인지 아는 것도 판을 쓰는 일의 일부입니다.

💡 한 줄 정리

판이 구현(클래스·태그·구조)을 붙잡으면 사용자에게 아무 일도 안 일어난 변경에 울고, 정작 사용자가 알아채는 변경은 놓친다. 역할·이름·상태를 붙잡으면 정확히 반대가 된다.

마무리

오늘 우리는 지난 시간의 마지막 문장을 들고 시작했습니다. 사용자는 "좋아요 라고 적힌 버튼"을 누른다고 했었죠.

그리고 첫 Step에서 그 문장이 우리 앱에서 그대로는 성립하지 않는다는 걸 봤습니다. 우리 버튼에는 글자가 없었어요.

  적힌 글자로 찾는다     →  못 찾거나, 엉뚱한 것을 잡는다
  읽히는 이름으로 찾는다  →  사용자가 보는 그것을 잡는다

그 "읽히는 이름"을 따라간 것이 오늘 하루입니다. 이름을 찾는 방법(getByRole), 이름이 어디서 오는지(aria-label), 이름으로 못 찾을 때의 순서, 그리고 그 이름을 사용자처럼 눌러보는 것까지요.

마지막 Step에서 그 선택의 값을 숫자로 확인했습니다. 사용자가 알아채는 변경 하나에 우리 판은 일곱 개가 울었고, 구현을 붙잡는 판은 하나도 안 울었어요.

오늘 배운 핵심 세 가지

💡 하나 — 화면에서 찾는 순서는 사용자에게 가까운 순서다. getByRole이 첫째인 이유는 그게 낭독기가 화면을 읽는 방식이기 때문이고, getByTestId가 마지막인 이유는 사용자가 그걸 볼 수 없기 때문이다. 우리 저장소의 369 대 12가 그 순서를 그대로 보여준다.

💡 둘 — 못 찾았을 때의 태도로 셋이 갈린다. 있어야 하는 것은 getBy, 없어야 하는 것은 queryBy, 곧 올 것은 findBy. 그리고 userEvent에는 항상 await를 붙인다 — 빼면 클릭이 아예 안 일어난다.

💡 셋 — 판이 붙잡아야 하는 것은 사용자가 인지하는 것이다. 역할·이름·상태를 붙잡으면 멀쩡한 변경에는 조용하고 진짜 변경에는 운다. 클래스·태그·구조를 붙잡으면 정확히 반대가 된다.

다음 시간 예고

오늘 우리가 확인한 화면들에는 공통점이 하나 있습니다. 전부 데이터를 이미 손에 쥔 채로 그려졌어요.

LikeButton에는 likeCount={1240}을 직접 넘겼고, CommentForm은 애초에 데이터가 필요 없었죠. 그래서 그리자마자 완성된 화면이 나왔습니다.

그런데 우리 앱의 진짜 피드는 그렇지 않아요. 서버에 물어보고, 기다리고, 도착하면 그때 그려집니다. Step 5에서 findBy를 소개하면서 "서버가 끼는 화면은 다음 시간에"라고 미뤄둔 게 이것 때문이에요.

그러면 판을 돌릴 때마다 진짜 서버를 띄워야 할까요? 그건 곤란합니다. 서버가 꺼져 있으면 판이 깨지고, 서버 데이터가 바뀌면 판이 또 깨지니까요.

지난 시간에 우리는 vi.mock으로 모듈을 통째로 갈아 끼워봤습니다. 그 방법을 화면에도 쓸 수 있을까요? 쓸 수는 있는데, 화면에서는 더 나은 방법이 있어요.

다음 시간에는 우리 코드를 한 줄도 안 고치고 서버 응답만 가로채는 방법을 배웁니다. 그러면 피드가 도착하는 화면도, 도착하다 실패하는 화면도 판으로 확인할 수 있게 돼요.

과제

[구현] 게시물 메뉴 버튼에 판을 써보세요

Step 2의 logRoles 출력을 다시 보면 PostCard에 버튼이 다섯 개 있었습니다. 그중 "게시물 메뉴"는 오늘 한 번도 안 다뤘어요.

PostHeader를 열어보고 그 버튼에 대한 판을 src/components/f3-post-header.test.tsx에 써보세요.

1. 그 버튼을 오늘 배운 우선순위대로 찾으세요. 가장 위쪽 방법으로 찾히나요?
2. 버튼의 접근성 이름이 어디서 오는지 소스에서 확인하세요. 좋아요 버튼과 같은 방식인가요?
3. 그 버튼 안에 들어 있는 것을 확인하는 판을 하나 쓰세요. textContent는 무엇이 나올까요?
4. 같은 화면에 PostHeader를 두 번 그려보세요. getByRole이 어떻게 되나요? Step 5에서는 { pressed: true }로 갈랐는데, 이 버튼에는 그렇게 쓸 것이 있나요? 없다면 좋아요 버튼과 무엇이 다른 걸까요?

마지막으로 답해보세요. 이 버튼은 지금 눌러도 아무 일이 안 일어납니다. 소스를 열어보면 알 수 있어요. 그런 버튼에도 판을 쓸 값어치가 있을까요?

[탐구] 우선순위를 어긴 판을 찾아보세요

Step 4에서 저장소의 쿼리 분포를 봤습니다. getByText가 177건이었죠.

대부분은 글자로 찾는 게 맞는 것들인데, 역할로 찾을 수 있는데 글자로 찾고 있는 곳이 섞여 있어요. 찾아봅시다.

1. getByText가 무엇을 찾고 있는지 훑어보고 몇 갈래로 분류해보세요. 개수·내용·안내 문구처럼 묶일 겁니다.
2. 그중 역할을 가진 요소를 글자로 찾는 곳이 두 군데 있습니다. 찾으세요. 하나는 오류 화면의 제목이고, 다른 하나는 카드 안에 있는 버튼이에요.
3. 그 둘을 getByRole로 바꿔 쓸 수 있는지 소스에서 확인하고, 실제로 바꿔서 판을 돌려보세요.
4. 1번에서 분류한 나머지들의 공통점을 한 문장으로 적으세요. 왜 그것들은 글자로 찾는 게 맞을까요?

답해보세요. 177건을 전부 getByRole로 바꾸는 것이 목표일까요? 지난 시간에 커버리지 숫자를 목표로 삼으면 안 된다고 했던 것과 이어서 생각해보세요.

[탐구] 판을 깨뜨려서 무엇을 지키는지 확인하세요

Step 8에서 우리는 구현을 다섯 가지로 바꿔봤습니다. 이번엔 반대로 해보세요.

CommentForm과 useCommentInput을 아래 세 가지로 각각 망가뜨리고, 매번 몇 개의 판이 빨개지는지 적으세요. 한 번에 하나씩만 바꾸고 확인한 뒤 되돌립니다.

1. useCommentInput의 content.trim() === ''을 content === ''로 바꾼다
2. CommentForm에서 disabled={isEmpty}를 지운다
3. CommentInput의 aria-label="댓글 입력"을 aria-label="댓글"로 바꾼다

답해보세요. 3번에서 빨개진 판을 고치는 올바른 방법은 무엇일까요? 판을 고쳐야 할까요, 코드를 되돌려야 할까요? 그 판단을 무엇을 근거로 하시겠어요?

[구현] 마우스 없이 쓸 수 있는지 확인하세요

Step 7의 🙋 에서 "마우스 없이 이 화면을 쓸 수 있나"를 물어보라고 했습니다. 댓글 폼으로 직접 확인해보세요.

1. userEvent.tab()으로 탭 이동을 흉내 낼 수 있습니다. CommentForm을 그려놓고 탭을 눌렀을 때 어디에 초점이 가는지 확인하세요.
2. 입력칸에 글자를 넣고 탭을 한 번 더 누르면 어디로 가나요?
3. 게시 버튼이 잠겨 있을 때와 풀려 있을 때, 탭 순서가 달라지나요?
4. 확인한 것을 판으로 적으세요. toHaveFocus() 매처를 쓸 수 있습니다.

답해보세요. 3번의 결과는 사용자에게 좋은 걸까요, 나쁜 걸까요? 잠긴 버튼을 탭 순서에서 빼는 것과 남겨두는 것 중 어느 쪽이 나을지 근거를 들어 답해보세요.

생각해볼 주제

1. 접근성이 먼저일까, 테스트가 먼저일까

오늘 우리는 aria-label 덕분에 버튼을 이름으로 찾을 수 있었는데, 그 aria-label은 테스트를 위해 붙인 게 아니라 A-4에서 접근성을 위해 붙인 것이었죠.

순서를 뒤집어 생각해볼 수도 있는데, 어떤 팀은 테스트를 쓰다가 접근성 문제를 발견합니다. "이 버튼을 역할로 못 찾겠는데?" 하고 열어보니 <div onClick> 이었던 거죠.

여러분의 팀에서 화면 하나를 새로 만든다고 해봅시다. 접근성을 챙기는 일과 테스트를 쓰는 일 중 무엇을 먼저 하시겠어요? 그 둘을 따로 하는 일이 아니라 한 가지 일로 만들려면 팀에 무엇이 있어야 할까요?

2. 판이 안 깨지는 것이 항상 좋을까

Step 8에서 우리는 구현을 바꿔도 안 깨지는 판이 좋은 판이라고 결론 냈습니다. 그런데 이 말을 끝까지 밀고 가면 이상한 곳에 도착해요.

아무것도 안 깨지는 판이 가장 좋은 판일까요? 예를 들어 expect(true).toBe(true)는 무엇을 해도 안 깨집니다.

그건 물론 아무것도 안 지키니까 나쁜 판인데, 좋은 판은 "안 깨지는 판"이 아니라 "깨져야 할 때만 깨지는 판"입니다.

문제는 그걸 어떻게 아느냐예요. 우리는 Step 8에서 구현을 다섯 가지로 직접 바꿔보고 확인했는데, 판이 수백 개인 저장소에서 이걸 매번 손으로 할 수는 없죠.

지난 시간 마지막에도 비슷한 질문을 했었습니다. 코드를 일부러 망가뜨렸을 때 안 빨개지는 판을 어떻게 찾을까 하고요. 오늘 화면 판에서도 같은 질문이 돌아왔어요. 이 두 질문은 같은 질문일까요, 다른 질문일까요?

3. 화면이 안 바뀌었는데 판이 깨질 때

M1을 다시 생각해봅시다. p-2를 px-2 py-2로 바꿨더니 구현을 붙잡는 판이 깨졌죠. 화면은 한 픽셀도 안 변했는데요.

이런 일이 팀에서 반복되면 어떻게 될까요? 사람들은 판을 고치는 데 지쳐서 두 가지 중 하나를 하게 됩니다. 판을 지우거나, 판을 안 보고 통과할 때까지 고치거나요.

둘 다 나쁜 결말인데, 흥미로운 건 이게 개인의 게으름 때문이 아니라는 점이에요. 거짓 경보가 반복되면 사람이 그 신호를 무시하게 되는 건 자연스러운 반응입니다.

여러분이 팀에 새로 들어갔는데 이런 판이 이미 수백 개 있다고 해봅시다. 전부 다시 쓸 시간은 없어요. 무엇부터 손대시겠어요? 새로 들어오는 판이 같은 문제를 안 만들게 하려면 팀에 어떤 약속이 필요할까요?