사용자 흐름 증거 묶음

증거는 재현 조건과 관찰값을 연결합니다

완성 화면 한 장만 있으면 검색 조건을 바꿨을 때, 상세에서 돌아왔을 때, 서버가 실패했을 때의 동작을 알 수 없습니다. 수료 자료는 기능 이름 목록이 아니라 재현 조건·기대 동작·실제 결과·근거를 연결한 묶음입니다. 이번 레슨은 EVIDENCE.md에 검색·상세·빈 결과·오류·모바일 다섯 흐름을 정리하고 자동 검사와 실제 화면 관찰의 범위를 구분합니다.

증거의 대상부터 고정합니다. 작성 중인 소스와 제출한 빌드가 다르면 캡처를 보고 코드를 평가할 수 없습니다. 실행 시각, 산출물 식별, manifest 해시, 브라우저 이름과 버전, 화면 크기를 기록합니다. 제출 후 코드가 바뀌면 영향을 받는 증거를 다시 만듭니다. 저장소 커밋이나 푸시 없이 파일 내용과 빌드 해시로 대상을 식별합니다.

각 흐름은 조건·행동 순서·기대 동작·실제 결과·근거·다음 행동을 갖습니다. “잘 됨” 대신 보인 제목과 건수, 유지된 검색어·지역, 상세에서 돌아온 위치를 씁니다. 예상과 달랐다면 실패 차이와 재현 절차를 남깁니다. 미실행 항목은 PENDING과 이유·실행 방법을 기록합니다. 관찰되지 않은 정보를 기대값으로 채워 넣지 않습니다.

검색 증거는 책과 busan 조건으로 시작합니다. 사용한 fixture를 함께 적고 결과 id·제목·지역·입력값·URL을 확인합니다. 검색 버튼이나 Enter를 사용했는지도 기록합니다. 같은 검색어라도 fixture가 달라지면 기대 결과가 바뀝니다. 원본 mock과 Playwright route는 다른 입력이므로 각각의 데이터 위치를 밝혀 건수 차이를 설명합니다.

상세는 검색 결과 id=2 링크에서 진입하고 제목과 목록 복귀를 확인합니다. 상세만 직접 열어 캡처하면 앞 검색 조건과 포커스 복원이 빠집니다. 목록으로 돌아왔을 때 검색어·지역과 원래 카드의 초점을 관찰합니다. 캡처는 화면을 보여 주고 테스트 assertion과 행동 기록은 전환을 설명하므로 두 종류의 자료를 연결합니다.

빈 결과는 존재하지않는행사라는 검색어를 사용합니다. 정상 응답 배열이 비고 0건 안내가 나타나며 오류 재시도는 숨겨져야 합니다. 서버를 끊어서 목록이 사라진 장면을 빈 결과로 쓰지 않습니다. 조건을 바꾸라는 안내가 적절한지 봅니다. 응답과 화면을 함께 확인하면 데이터 없음과 처리 실패를 혼동하지 않았는지 판단할 수 있습니다.

오류는 route fixture에서 HTTP 500을 반환하고 다음 요청은 정상 rows로 돌려보내 재현합니다. 오류 안내와 다시 시도 후 정상 복구를 기록합니다. 서버 실패와 연결 실패는 별도 검사 이름으로 구분합니다. 콘솔에 에러가 없다는 사실만으로 오류 흐름을 검증하지 않습니다. 사용자가 다음 행동을 선택할 수 있는 문구와 실제 복구 결과를 확인합니다.

모바일은 390×900 viewport에서 긴 연속 제목이 있는 목록과 상세를 모두 확인합니다. 가로 넘침은 documentElement의 scrollWidth와 clientWidth 차이로 계산합니다. 자동 검사 허용 오차는 1px입니다. 390px 캡처로 다른 모든 폭을 검증했다고 쓰지 않습니다. 320·1280px 자동 검사를 별도 연결하고 viewport 에뮬레이션과 실제 기기를 구분합니다.

키보드 관찰은 마우스를 사용하지 않은 절차로 남깁니다. Tab으로 검색어·지역·카드 링크·복귀 링크에 도달하고 Enter로 행동합니다. 초점 표시와 전환 뒤 위치를 확인합니다. 포커스 링 한 장으로 전체 순서를 증명할 수 없습니다. 시작 위치·행동·최종 위치를 적거나 테스트 이름을 연결해 관찰한 구간을 분명히 합니다.

Playwright는 고정 route를 제공해 실패와 응답 역전을 반복 가능하게 만듭니다. npm run test:built로 현재 dist를 대상으로 검사합니다. Chromium이 없다면 설치 실패와 기능 assertion을 섞지 않습니다. PENDING은 성공이 아니라 검증이 남았다는 뜻입니다. 최종 제출 전 실행 가능한 환경에서 해소할 계획을 적고 수료 완료로 표시하지 않습니다.

Node 모델과 브라우저에는 다른 결과 칸을 둡니다. Node는 상태와 카드 생성 계약을 검사하고 브라우저는 DOM 연결·URL·초점·CSS 배치를 관찰합니다. 모델 통과를 캡처 대신 쓰거나 캡처를 API 회귀 대신 쓰지 않습니다. 자동화는 반복 가능한 반례를, 수동 검토는 사용자 문구와 화면 맥락을 살피는 데 도움이 됩니다. 주장에 맞는 근거를 고릅니다.

근거 파일은 상대 경로로 연결합니다. evidence/search-390.png처럼 행동과 폭이 드러나는 이름을 쓰고 원본 로그와 trace를 함께 연결합니다. trace에는 요청 데이터가 있으므로 공개 허용 fixture인지 확인합니다. 개인 알림·토큰·실제 사용자 정보가 담긴 캡처는 제출하지 않습니다. 자료의 개수보다 주장과 근거의 연결이 중요합니다.

예상 결과를 실제 결과 칸에 복사하면 증거가 무효가 됩니다. 자동 검사가 통과했다면 명령·검사 이름·종료 코드·범위를 적습니다. 화면을 보지 않았다면 “카드가 보기 좋다”라는 시각적 평가를 추가하지 않습니다. 제공 solution 문서는 작성 예시이며 실제 브라우저 관찰은 PENDING입니다. 학습자는 자신의 실행값과 실제 화면으로 갱신합니다.

상충하는 자료는 조건을 비교합니다. 어떤 빌드·fixture·폭에서 달라졌는지 확인합니다. Node는 정상인데 화면이 비면 모듈 로드·요청 URL·응답 형식을 조사합니다. 소스에서는 되고 dist에서는 안 되면 빌드 포함 파일을 봅니다. 실패 기록은 후속 수정의 출발점이 되도록 유지합니다. 통과 결과만 남기면 같은 문제를 다시 재현하기 어려워집니다.

검토자에게는 다섯 흐름을 찾아 실행할 수 있는 색인을 줍니다. 각 항목에 조건과 근거를 붙이고 큰 로그는 원본 파일로 연결합니다. 본문에는 핵심 값과 제한을 요약합니다. 테스트 총 개수만 적으면 빈 결과와 오류 구분이 검사됐는지 알기 어렵습니다. 행위별 자료와 코드 위치가 있어야 프로젝트 평가가 추가 질문에만 의존하지 않습니다.

이 설계 실습의 제출물은 EVIDENCE.md와 실제 390px 목록·상세 캡처입니다. 미션 solution의 골격에서 다섯 흐름을 실행하고 기대와 실제를 비교합니다. 더 읽기의 테스트 장에서는 자동화 전략을 넓혀 읽습니다. 여기서는 자료 대상과 관찰 결과의 연결을 완성하고 미확인 항목은 해결될 때까지 정확하게 표시합니다.