API와 UI의 역할 나누기

자동화할 질문을 먼저 고릅니다

가입 버튼을 누르는 동작을 코드로 만들었다고 가입 검증이 완성되지는 않습니다. 사용자 입력이 서버로 전달되는지, 결과를 읽을 수 있는지, 다음 행동으로 이어지는지를 관찰해야 합니다. QA는 도구를 고르기 전에 찾으려는 결함을 적습니다. 동아리 회원 서비스에서는 가입 성공인데 화면이 그대로인 결함과 중복 가입인데 성공 안내가 뜨는 결함이 UI 검사의 좋은 대상입니다.

앞 모듈은 응답 코드와 저장 행을 확인하고 자기 실행의 계정을 정리했습니다. 이 근거 위에서 이번 모듈은 가입→로그인→프로필 수정→로그아웃이라는 사용자 여정을 추가합니다. API 검사가 빠르다는 이유로 UI 검사를 없애거나, 사용자가 보는 화면이라는 이유로 모든 경계 조합을 UI로 옮기지 않습니다. 관찰 지점이 다른 검사를 연결하여 결함 위치를 좁힙니다.

API와 UI가 서로 다른 증거를 만듭니다

API에서 비밀번호 길이 7·8·64·65, 중복 이메일, 타인 조회 거절을 검사하면 입력 규칙과 권한 계약을 직접 관찰합니다. 저장 전후의 정확한 행과 닉네임을 비교하면 성공처럼 보이는 응답 뒤 잘못된 DB 변경도 찾습니다. 반면 이 결과로 label 연결, 버튼 접근, 오류 안내, 포커스 이동이 정상이라고 판단할 수 없습니다. 각 검사가 확인한 층을 보고서에 분명하게 적습니다.

UI에서는 이메일을 입력하고 가입하기를 누른 뒤 가입 완료 안내를 확인합니다. 프로필 수정 후 저장 완료 문구뿐 아니라 다시 조회한 닉네임도 기대값과 비교합니다. 버튼 클릭 성공은 브라우저가 행동을 수행했다는 증거입니다. 업무 완료는 별도의 단언으로 확인합니다. 저장 API가 정상인데 화면에 이전 닉네임을 그리는 결함은 이 단언에서 드러납니다.

한 테스트가 여러 층을 검사하는 것도 가능합니다. 핵심 여정에서는 UI로 저장한 뒤 동일 세션의 API로 닉네임을 다시 읽습니다. 화면 기대값과 저장 기대값을 구별해 실패 이름을 붙이면 저장 오류인지 화면 반영 오류인지 조사하기 쉽습니다. 모든 UI 테스트에 DB 내부 구조를 노출하기보다 저장의 상세 경계 조합은 기존 API·H2 검사에 맡깁니다.

범위 선택표를 작성합니다

추적표에는 요구사항 ID, 인수 기준, 사례 ID, 검사 층, 관찰값, 유지 비용, 제외 근거를 둡니다. 예를 들어 가입 중복 거절에는 API 응답 409와 행 무변경 검사, UI 오류 문구 검사 두 행을 연결합니다. 같은 요구에 두 검사를 연결해도 각각 찾으려는 결함이 다릅니다. 요구사항 ID는 앞 모듈 spec의 실제 ID를 사용하며 새 번호를 임의로 만들지 않습니다.

UI 여정은 정상 흐름 한 개와 의미가 다른 실패 사례를 선택합니다. 중복 이메일은 상태 충돌, 잘못된 비밀번호는 인증 거절, 세션 만료는 로그인 후 권한 변화, 일시 오류는 복구 행동을 봅니다. 비밀번호 모든 길이 조합을 같은 여정으로 반복하면 실패 조사와 실행 비용이 늘어납니다. 빠른 검사에 남긴 조합을 표에 기록하여 생략이 요구 누락으로 오해되지 않게 합니다.

수동 탐색은 자동화 목록의 빈칸을 찾는 작업입니다. 화면 문구가 이해되는지, 좁은 폭에서 내용이 잘리는지, 새로운 오류 뒤 사용자가 어디로 가야 할지 등을 관찰합니다. 키보드 순서 일부를 자동 검사하더라도 전체 접근성 적합성을 증명하지 않습니다. 확인한 브라우저와 경로, 제외한 보조 기술과 이유를 따로 쓰며 미검증을 정상으로 표시하지 않습니다.

비용과 실패의 의미를 연결합니다

유지 비용에는 실행 시간뿐 아니라 데이터 준비, 화면 변경 때 선택자 수정, 실패 증거 검토가 들어갑니다. 제목이 바뀔 때마다 깨지는 긴 CSS 경로를 쓰면 테스트가 기능 변경보다 HTML 구조 변경에 반응합니다. 오류를 잘 찾는 검사가 자주 깨진다면 삭제부터 결정하지 않고 선택자와 상태 대기, 격리 준비가 요구와 맞는지 점검합니다.

테스트 선택표에는 제외를 검토할 조건도 둡니다. 가입 폼의 비밀번호 안내가 바뀌면 입력 경계 API 검사를 유지하면서 새 안내 UI 검사를 추가할 수 있습니다. 세션 정책이 바뀌면 만료 후 화면과 재인증 흐름을 다시 선택합니다. 한 번 작성한 자동화 범위를 영구 목록으로 취급하지 않고 변경된 사용자 위험을 기준으로 갱신합니다.

이번 실습 환경과 실행 경로입니다

로컬 압축은 Java 17·Spring Boot 3.1.5 앱, Maven wrapper, Node 검증 코드, Playwright 1.63.0의 잠금 파일을 제공합니다. Node는 20 이상을 사용합니다. 처음 준비할 때 앱 폴더에서 ./mvnw test, 앱 안 ui 폴더에서 npm ci와 npx playwright install chromium을 실행합니다. 이후 압축 루트의 bash check.sh가 핵심 검사와 브라우저 검사를 묶습니다. 설치 오류를 제품 단언 실패로 분류하지 않습니다.

작성 환경의 Chrome은 기동 직후 종료되어 실제 브라우저 검사는 external로 표시했습니다. 브라우저 출력이 빈 따라하기는 미실행이며 통과를 주장하지 않습니다. 외부 검증자는 브라우저를 준비한 뒤 check.sh를 실행합니다. bash check-core.sh는 오프라인 Maven과 Node 검사를 실행하지만 화면 렌더링·포커스·스크린샷의 증거가 되지 않습니다. PENDING은 아직 검증 결과가 없다는 뜻입니다.

JUnit은 새 H2와 임의 포트의 로컬 Spring 앱을 만들고 Node의 브라우저 검사 종료 후 앱을 닫습니다. UI는 실제 제공 API를 호출하며 지연과 503은 테스트가 지정한 요청에만 주입합니다. 로그아웃과 만료·정리 API는 src/test에만 추가한 실습 지원 기능입니다. 운영 설정이나 실재 계정은 사용하지 않고 다른 실행·기존 합성 계정은 정리 후에도 보존합니다.

제출물은 판단을 검토할 수 있게 만듭니다

이번 레슨은 문서 실습입니다. 앞 추적표를 복사해 API·UI·수동 탐색을 나눈 여섯 사례 이상을 작성하고 각 행에 실제 관찰값을 적습니다. 정상 여정, 중복, 세션 만료, 지연, 오류 복구, 키보드 이동을 포함합니다. 여기에 비밀번호 경계 조합을 API에 남긴 이유와 전체 접근성 검사를 제외한 이유를 적고 후속 확인 담당과 조건을 둡니다.

리뷰어는 표를 보고 어떤 요구가 어느 검사에서 확인되는지, 실패했을 때 무엇을 다시 실행할지 찾을 수 있어야 합니다. UI 칸에 성공만 쓰면 클릭 성공과 저장 성공을 구분할 수 없으므로 저장 완료 문구와 다시 조회한 닉네임처럼 관찰 항목을 구체화합니다. 코드가 아직 없는 행은 계획 상태로 남깁니다. 반례를 만드는 일반 사고 방식은 더 읽기의 서재 장에서 확장합니다.