통합·인수·회귀 테스트
단위·통합·시스템·인수 검증의 책임을 나누고 저장 복원 경계를 포함한 회귀 사례를 실행합니다.
신청 함수만 맞아도 저장 파일을 읽을 때 참가자 목록이 빠지면 다음 실행에서 정원을 잘못 계산합니다. 개별 부분의 규칙과 부분 사이의 연결을 각각 검증해야 합니다.
단위 테스트는 작은 책임을 격리해 확인하고, 통합 테스트는 부분이 연결되는 경계와 계약을 확인합니다. 시스템 테스트는 완성된 시스템의 전체 동작·품질을, 인수 테스트는 업무 목적과 수락 기준을 확인합니다. 사용하는 도구가 아니라 범위와 판단 책임으로 구분합니다.
저장 경계의 실제 사례
다음 코드를 examples/roundtrip.mjs로 저장합니다. 실제 파일 I/O 대신 JSON 변환이라는 경계를 확인하는 작은 통합 예입니다.
import assert from "node:assert/strict";
import { createSession, register, restoreSession } from "../core.mjs";
const initial = createSession({ id: "book-1", title: "첫 책", capacity: 2 });
const saved = register(initial, "min").state;
const encoded = JSON.stringify(saved);
const restored = restoreSession(JSON.parse(encoded));
assert.deepEqual(restored.participants, ["min"]);
assert.equal(register(restored, "min").code, "ALREADY_REGISTERED");
assert.equal(register(restored, "hana").code, "REGISTERED");
console.log("roundtrip PASS");직렬화는 값을 저장·전송할 표현으로 바꾸는 일이고 복원은 그 표현을 다시 유효한 상태로 만드는 일입니다. JSON을 읽었다는 이유만으로 상태가 유효한 것은 아닙니다. restoreSession은 중복 ID·정원 초과·알 수 없는 상태를 거절합니다. 실제 디스크 쓰기 실패나 두 프로세스의 경쟁은 위 예제로 검증되지 않으며 저장 방식 변경에서 더 다룹니다.
수준과 기법은 다른 분류
| 질문 | 분류 축 | 모임 사례 |
|---|---|---|
| 어디까지 연결해 확인하나? | 단위·통합·시스템 | register 단독, 저장 후 복원, 화면부터 저장까지 |
| 무엇을 근거로 사례를 고르나? | 명세·구조 | 정원 경계, 거절 분기 |
| 어떤 변경 위험을 확인하나? | 회귀 | 저장 교체 후 중복 거절 유지 |
| 누가 어떤 목적을 수락하나? | 인수 | 진행자가 마감·취소 업무 시나리오 확인 |
회귀 테스트는 변경으로 이미 되던 동작이 깨졌는지 재검사합니다. 새 기능 테스트와 기존 기능 테스트를 함께 선택합니다. 단순히 모든 테스트를 반복하는 것만이 회귀 전략은 아니지만, 작은 코어에서는 전체 실행 비용이 낮아서 전체를 반복하기 쉽습니다.
통합 순서를 위에서 아래로 선택하면 아직 없는 하위 부분을 대신하는 스텁, 아래에서 위로 선택하면 호출자를 대신하는 드라이버가 필요할 수 있습니다. 모두 한꺼번에 연결하는 빅뱅 방식은 실패 원인을 찾기 어렵습니다. 이 교재는 코어→저장→전체 업무처럼 경계를 하나씩 연결합니다. 테스트 대역이 실제 저장의 오류와 계약을 대신 검증한다고 착각하지 않습니다.
인수 시나리오의 관찰점
진행자는 “두 자리 모임에 min·hana 신청→min 취소→jun 신청→마감→새 신청 거절→hana 취소”를 수행합니다. 명단과 결과 메시지, 마감 상태를 확인합니다. 자동 테스트는 상태와 코드 증거를 만들고 진행자 검토는 메시지가 업무에 맞는지 확인합니다. 사용성·권한·실제 복구는 해당 기능이 있는 환경에서 별도로 확인합니다.
독립 문제: 스텁에서는 통과한 저장
항상 성공하는 저장 스텁을 쓴 테스트가 통과했지만 실제 저장에서 권한 오류가 납니다. 추가할 통합 사례와 사용자에게 보여 줄 정책을 제안하세요.
힌트
실패가 명단 변경 전인지 후인지, 성공으로 표시해도 되는지 생각합니다.
해설
실제 저장 경계에서 쓰기 실패를 재현하거나 오류를 던지는 대역으로 애플리케이션 처리를 확인합니다. 저장이 확인되지 않았다면 신청 성공으로 안내하지 않는 정책을 정합니다. 이전 저장 상태가 보존되는지, 재시도 때 중복 처리되지 않는지 확인합니다. 실패 주입은 애플리케이션의 오류 처리 증거이고 실제 운영체제 권한·디스크 동작의 확인을 모두 대신하지는 않습니다.
정적 검토는 실행 전에 명세·코드를 살피고 동적 테스트는 실행 결과를 봅니다. 테스트만 뒤에 몰아넣기보다 요구·설계 검토와 실행 검증을 이어서 사용합니다.