Writes, reviews, and debugs property-based tests, which generate inputs to check general rules. Helps test conversions, parsers, normalization, and state invariants, assess whether existing assertions are meaningful, and distinguish faulty rules from implementation bugs.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Writes, reviews, and debugs property-based tests — Hypothesis, fast-check, proptest, jqwik, rapid, and Echidna or Medusa for Solidity invariants. Use whenever tests should cover a whole input domain instead of a hand-picked list of examples: encode/decode and serialize/deserialize pairs, parsers, canonicalizers and normalizers, validators, numeric and Decimal types, comparators and sort order, data structures, and smart-contract state invariants. Also use when adding cases to an existing @given, fast-check, or proptest suite, when judging whether existing property tests assert anything real, and when a generator has shrunk a counterexample and you need to tell a wrong property from a genuine bug. Not for coverage-guided binary fuzzing (libFuzzer, AFL), mutation-testing campaigns, static analysis, benchmarking, or end-to-end UI tests.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
An example test asserts one point. A property asserts a rule over the whole input domain and lets the generator hunt for the counterexample. That trade is worth making when the code has an algebraic shape — an inverse, an invariant, an oracle — and not otherwise. Code with no such shape gets example tests; saying so is a valid outcome.
Check first whether the shape is missing or merely buried. A calculation wrapped in I/O, a string built by concatenation, an in-place mutation — each has a property and no seam to assert it through. See references/refactoring.md before concluding there is nothing to assert.
| Property | Formula | Where it applies |
|---|---|---|
| Roundtrip | decode(encode(x)) == x | Serialization, conversion pairs |
| Inverse | f(g(x)) == x | encrypt/decrypt, compress/decompress |
| Oracle | new(x) == reference(x) | Optimization, refactoring, reimplementation |
| Idempotence | f(f(x)) == f(x) | Normalization, formatting, sorting |
| Invariant | Holds before and after | Any transformation, contract state |
| Easy to verify | is_sorted(sort(x)) | Complex algorithms with cheap checkers |
| Commutativity | f(a, b) == f(b, a) | Binary and set operations |
| Associativity | f(f(a,b), c) == f(a, f(b,c)) | Combining operations |
| Identity | f(x, e) == x | Operations with a neutral element |
Strength ordering, weakest to strongest:
no crash → type preservation → invariant → idempotence → roundtrip / oracle.
Assert the strongest property the code supports. "No crash" alone rarely justifies the dependency — if that is all you can find, either a small rearrangement exposes something stronger, or the honest report is that this code is a poor PBT candidate. Rule out the first before settling for the second.
assert add(a, b) == a + b restates the implementation; no bug they
share can fail it. Pick a property that constrains the function without recomputing
it. Note the exception: f(x) == f(x) is a genuine determinism property when f
is not obviously pure — serializers over dicts or sets, hashing, anything reading
the clock.assume() that filters out nearly every input passes without
exercising anything, and self-contradictory assume() passes having run zero cases.
Push constraints into the strategy so the generator produces valid inputs directly.Load the one that matches the task in front of you:
| Task | File |
|---|---|
| Writing new tests, designing strategies | references/generating.md |
| The code has no property to assert yet | references/refactoring.md |
| Reviewing existing property tests | references/reviewing.md |
| A property test just failed | references/interpreting-failures.md |
| Library choice, Echidna and Medusa | references/libraries.md |
If the project already uses a PBT library, just write the tests in it. If it does not, adding one is a dependency decision that belongs to the user — offer it once with the specific property you would write, and take the answer either way.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Build and test code with AddressSanitizer, a tool that detects invalid memory access during execution. Configure checks for C/C++ and unsafe Rust, investigate crash reports, and adjust settings for fuzzing, or testing with generated inputs.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Sets up AFL++ to test C/C++ programs with varied generated inputs, a technique called fuzzing. Covers running tests across CPU cores, monitoring progress, reducing input collections, and reproducing crashes for investigation.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Audits GitHub Actions workflows that run AI coding agents. Traces how attacker-controlled content reaches prompts, checks permissions and sandbox settings, and reports evidence, severity, and fixes for prompt injection and related configuration risks.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Reviews Algorand smart contracts written in TEAL or PyTeal for 11 vulnerability patterns. Produces a complete coverage table and findings with code references, severity ratings, and suggested fixes, with optional automated checks using Tealer.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Set up Atheris to test Python code and C extensions with automatically varied inputs. It guides test harness creation, coverage tracking to explore more code, and AddressSanitizer setup for finding memory errors.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Connect static analysis results and human audit notes to a Trailmark code graph. Group findings by severity and compare them with input flow, impact, and privilege boundaries to prioritize investigation and understand findings in their code context.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.