Property-based 테스트

목표

구현이 Spec에 적은 대로 동작하는지 property-based 테스트(PBT)로 확인하는 흐름과 그 한계를 파악합니다.

기능	IDE	CLI	Web	Mobile
Property-based testing	✓	—	—	—

대부분의 테스트는 예시 기반입니다. 구체적인 입력 하나를 넣고 기대 결과 하나를 확인합니다. 사람이든 AI든 떠올린 예시까지만 검증됩니다.

PBT는 반대로 항상 성립해야 하는 일반 규칙을 적고, 도구가 수백~수천 개의 무작위 입력을 만들어 그 규칙을 깨뜨리려고 시도합니다. fuzzing, generative testing도 같은 계열입니다.

속성은 데이터와 무관하게 성립해야 하는 동작입니다. 형식은 "전제 조건을 만족하는 모든 입력에 대해 어떤 동작이 참이다"이고, EARS 요구사항과 잘 맞습니다.

인증된 모든 사용자와 활성 상태인 모든 매물에 대해, 사용자는 그 매물을 볼 수 있다.

자동차 판매 앱의 예:

PBT는 사용자 A와 1번 차, 사용자 B와 500번 차, 이름에 특수문자가 든 사용자, 상태가 다양한 차 등 수많은 조합을 시험합니다.

실패를 일으킨 무작위 입력은 보통 크고 지저분합니다(200자 사용자명, 1,000대짜리 목록). Shrinking은 같은 실패를 재현하는 가장 작은 입력(빈 문자열 하나, 원소 두 개짜리 목록 등)으로 줄여서 원인을 바로 보이게 합니다.

장점:

한계:

정확성의 증거이지 증명이 아닙니다. 형식 검증이 아니므로 통과해도 버그가 없다고 보장하지 않습니다.
쓸모 있는 속성을 정하는 데 노력이 듭니다. 너무 약하거나 잘못된 속성은 실제 동작이 틀려도 통과합니다.
모든 요구사항이 속성으로 깔끔하게 바뀌지 않습니다. 외부 서비스나 비결정적 동작에 크게 의존하면 mock이 필요하거나 예시 기반 테스트가 더 낫습니다.

text

Requirements → 속성 추출 → 작업에 추가 → 테스트 실행 → 실패 식별 → 수정·재검증

Design 단계: Kiro가 EARS 요구사항에서 테스트 가능한 속성을 뽑습니다. 속성에 마우스를 올리면 원래 요구사항과 연결된 작업이 보입니다.
작업 실행 단계: 생성된 PBT를 구현에 대해 실행합니다. PBT는 기본적으로 선택 사항이라 핵심 구현을 먼저 할 수 있습니다.
실패했을 때: Kiro가 실패 시나리오를 보여 줍니다. 채팅으로 원인을 파악한 뒤 구현, 테스트, 요구사항 중 무엇을 고칠지 정합니다. Kiro가 구현을 자동으로 고치거나 수정 선택지를 제시하기도 합니다.

Bugfix Spec에서는 이 PBT가 버그 재현, 수정 확인, 회귀 없음을 검증하는 데 쓰입니다.