property-based-testing

property-based-testing 개요

이 property-based-testing 스킬은 무엇을 위한 것인가

property-based-testing 스킬은 예시 기반 테스트만으로는 충분한 확신을 얻기 어려울 때, property-based test를 작성하고 검토하고 개선하도록 도와줍니다. 특히 roundtrip, invariant, parser, validator, normalizer, sorting logic, smart contract state rule을 검증해야 할 때 property-based-testing 스킬이 유용합니다.

가장 큰 도움을 받는 사람

가장 잘 맞는 대상은 성숙한 PBT 라이브러리가 있는 언어를 쓰는 엔지니어, 약한 테스트를 점검하는 리뷰어, 그리고 기능을 처음부터 property로 명세하는 편이 더 자연스러운 개발자입니다. property-based-testing을 설치할지 고민 중이라면 핵심 질문은 코드에 재사용 가능한 구조가 있는지, 변환이 되돌릴 수 있는지, 또는 많은 입력 전반에 걸쳐 성립해야 하는 규칙이 있는지입니다.

무엇이 다른가

이 스킬은 일반적인 테스트 프롬프트와 달리 detection, property 선택, strategy 설계, failure 해석을 중심으로 구성되어 있습니다. 이런 구성이 중요한 이유는 도입을 막는 가장 큰 장벽이 문법이 아니라, 유용한 property를 고르고 과도한 filtering 없이 유효한 입력을 생성하는 일이기 때문입니다. 이 스킬은 property-based-testing for Skill Testing처럼 여러 생태계 전반에 적용할 수 있을 만큼 넓은 범위를 가지며, smart contract도 포함합니다.

property-based-testing 스킬 사용법

적절한 컨텍스트를 설치하고 불러오기

npx skills add trailofbits/skills --skill property-based-testing로 설치한 뒤, 먼저 SKILL.md를 여세요. 더 빠르게 판단하려면 README.md와 작업에 가장 관련 있는 참고 파일도 함께 읽는 것이 좋습니다: references/generating.md, references/reviewing.md, references/interpreting-failures.md.

대략적인 아이디어를 쓸 만한 프롬프트로 바꾸기

좋은 property-based-testing usage 프롬프트는 대상, operation, 그리고 원하는 guarantee를 모두 밝혀야 합니다. 더 나은 입력 예: “이 serializer에 대해 decode(encode(x))용 PBT를 추가하되, 입력은 유효한 UTF-8과 size limit 안에서 유지해 주세요.”
좋지 않은 입력 예: “이 모듈에 property test를 작성해 주세요.”
첫 번째 예시는 스킬이 실제 property, 유효한 domain boundary, 출력 형태를 파악할 수 있게 해 줍니다.

요청에 포함해야 할 내용

언어, 테스트 라이브러리, 함수 시그니처, 알려진 invariant, 잘못된 입력에 대한 동작, 그리고 예시나 spec이 있으면 함께 넣으세요. 리뷰 용도로 property-based-testing guide를 사용하는 경우라면 현재 테스트를 붙여 넣고, bug finding인지 refactoring인지 quality audit인지도 설명해 주세요. 코드에 parsing이나 validation 경로가 있다면 malformed data가 들어왔을 때 무엇이 일어나야 하는지 적어 주세요. 그래야 애매한 테스트와 잘못된 assume() 사용을 피할 수 있습니다.

권장 워크플로

먼저 코드를 property type으로 매핑하세요: roundtrip, idempotence, invariant, ordering, oracle 중 무엇인지 정합니다. 그다음 heavy filtering에 기대지 말고, 전략으로 유효한 입력을 생성하도록 설계하세요. 마지막으로 references/interpreting-failures.md를 보고 failure를 해석한 뒤에야 bug로 판단하세요. smart contract 작업이라면 EVM 전용 노트를 확인하고 state model을 명시적으로 유지해야 합니다.

property-based-testing 스킬 FAQ

property-based-testing은 일반 테스트를 대체하나요?

아니요. 이 스킬은 일반적인 예시 테스트가 놓치는 edge case가 많거나, 하나의 property로 여러 동작을 설명할 수 있을 때 가장 큰 가치를 냅니다. 좁은 regression에는 예시 테스트를 유지하고, 몇 개의 사례보다 일반 규칙이 더 분명할 때는 property-based-testing을 사용하세요.

이 property-based-testing guide는 초보자에게도 친절한가요?

네, 대상 동작이 단순하고 property가 명확할 때는 그렇습니다. 예를 들어 roundtrip이나 idempotence 검사처럼 말이죠. 하지만 spec이 충분히 구체적이지 않으면 어렵습니다. PBT는 generator를 유용하게 만들기 전에 명확한 contract가 먼저 필요하기 때문입니다.

언제 이 스킬을 쓰지 말아야 하나요?

동작이 주로 UI 중심이거나, 매우 비결정적이거나, 안정적인 property로 표현할 수 없을 때는 가장 먼저 이 스킬을 꺼내지 마세요. 또한 유일한 oracle이 production code를 그대로 따라 한 긴 reimplementation chain뿐이라면 이 스킬은 잘 맞지 않습니다.

내 언어나 프레임워크에도 맞나요?

이 스킬은 Hypothesis, fast-check, proptest, jqwik, ScalaCheck, FsCheck, StreamData, QuickCheck, 그리고 Echidna와 Medusa 같은 smart contract fuzzer를 포함해 다양한 생태계를 지원합니다. 스택이 이 목록 밖에 있더라도 기본 방법은 여전히 도움이 되지만, 테스트 문법과 strategy API는 직접 맞춰야 할 수 있습니다.

property-based-testing 스킬 개선 방법

대상을 말하는 데서 끝내지 말고, 가장 강한 property를 제시하세요

가장 좋은 결과는 정확한 보증을 명시할 때 나옵니다. 예를 들어 “Unicode string에 대해 normalize(normalize(x)) == normalize(x)”는 “normalize를 테스트해 주세요”보다 훨씬 낫습니다. property-based-testing 스킬은 property가 구체적이고, 반증 가능하며, 이미 알려진 contract와 연결될 때 더 잘 작동합니다.

generator를 좌우하는 제약을 함께 알려 주세요

흔한 실패 원인은 잘못된 입력, 과도하게 필터링된 strategy, 그리고 실제 버그를 잡아내기엔 너무 약한 property입니다. 허용 범위, 형식 규칙, size limit, 예외가 기대되는지 여부를 적어 주면 출력 품질이 좋아집니다. 어떤 property가 validation 이후에만 성립해야 한다면 그것도 분명히 밝혀 주세요.

실패한 예시를 바탕으로 반복 개선하세요

첫 테스트가 실패했다고 해서 바로 수정만 요청하지 마세요. 축소된 counterexample, 의도한 규칙, 그리고 edge-case 동작을 정의한 문서를 함께 제공하세요. 그러면 스킬이 실제 bug와 잘못된 property를 구분하고, 더 강한 2차 테스트나 refactor 제안을 만들어 낼 수 있습니다.