← Belső rendszer fejlesztők adatlapja
Nézd meg, miben segít
Tulajdonságalapú tesztelés
Sok érvényes üzleti eset generálásával vizsgálja a kézi példákból gyakran kimaradó szabályhatárokat.
property-based-testing
Ezt a skillt használó csapattagok
Mikor hasznos?
Akkor használd, ha összegek, kapcsolatok vagy műveletsorok kombinációján múlik a helyesség.
Miben segít neked?
- Közvetlenül érvényes objektumot épít sok eldobott véletlen helyett.
- Következetesen generál kapcsolt entitásokat és határértékeket.
- Meglévő tesztkeretbe illeszt, reprodukálható hibát rögzít.
Például ezt kérheted
Generálj visszatérítéseket nulla, terhelt összeg és ismételt kérés körül a meglévő tesztfuttatóban. Érvényes terheléshez generálj korlát alatti, azzal egyező és feletti visszatérítést. Szabálysértésnél őrizd a véletlenmagot és legkisebb ellenpéldát.
Részletes dokumentáció
Itt a skill eredeti útmutatóját, példáit és ellenőrzési szempontjait olvashatod az eredeti nyelven.
Összecsukás
Property-Based Testing
Use this skill when implementing property-based tests, custom generators (Arbitrary / Strategy / Gen), input distributions, and property assertions.
Ecosystem & Tooling Alignment
- Adapt to the repository's language and existing test runner before proposing dependencies:
- TypeScript / JavaScript:
fast-checkwith Vitest or Jest. - Python:
Hypothesiswithpytest. - PHP / Laravel: PHPUnit data providers / Eris / QuickCheck-style generators integrated with Pest or PHPUnit.
- Rust / Go / JVM:
proptestorquickcheck(Rust),rapidorpgregory.net/rapid(Go),jqwikorScalaCheck(JVM).
- TypeScript / JavaScript:
- Do not introduce a new testing framework without clear justification when the project already has one.
Generator Design Principles (Hughes & Claessen)
- Construct Valid States by Design, Not by Filtering:
- Build domain objects compositionally (
fc.record,st.composite,prop_compose!) so generated values satisfy structural constraints by construction. - Avoid heavy
.filter()/assume()chains that discard most samples and cause health-check failures or starvation of deep paths.
- Build domain objects compositionally (
- Generate Dependent Entities Coherently:
- Use monadic chaining (
chain/flatMap/@st.composite) when one input depends on another: e.g., generate a payment first, then generate a partial refund amount in $[1, \text{payment.capturedAmount}]$, or generate a workspace first, then draw actors and resources from that workspace's membership pool.
- Use monadic chaining (
- Weight Boundary and Adversarial Values Explicitly:
- Pure uniform random numbers rarely hit exact thresholds. Bias generators toward domain boundaries:
- Zero, $1$ minor unit, $\text{threshold} - 1$, $\text{threshold}$, $\text{threshold} + 1$, maximum allowed limit, and exact expiration timestamps.
- Empty collections, single-element collections, duplicate items, and multi-item batches with identical keys.
- Pure uniform random numbers rarely hit exact thresholds. Bias generators toward domain boundaries:
- Preserve Shrinkability:
- Build custom generators by mapping and composing library primitives rather than drawing raw random bytes or calling
Math.random()/random.randint()outside the PBT engine, which breaks integrated shrinking.
- Build custom generators by mapping and composing library primitives rather than drawing raw random bytes or calling
Execution Budgets: CI vs. Exploratory Profiles
- Fast CI Profile: Configure a deterministic or bounded run budget (e.g.,
numRuns: 100–250, explicit per-test timeout, zero external network calls) so the suite runs reliably in seconds on every pull request. - Deep Exploratory Profile: Expose an environment-driven override (e.g.,
PBT_RUNS=5000orHYPOTHESIS_PROFILE=deep) for stress-testing complex state spaces and rare boundary combinations during investigation. - Strict Test Isolation: Reset in-memory stores, database transactions, fake clocks, and queues between every generated sample (
beforeEach/ per-iteration setup) so sample $N$ never leaks state into sample $N+1$.
Checklist
- Do generators construct valid domain structures directly instead of relying on high-rejection
.filter()/assume()predicates? - Are dependent values (e.g., refund vs. payment, line items vs. invoice currency) chained from their parent entities?
- Are boundary values ($0$, $1$, $\text{limit}-1$, $\text{limit}$, $\text{limit}+1$) explicitly represented in the generator distribution?
- Is state completely isolated between individual generated iterations, with bounded runtime suitable for CI?
Csomagban lévő fájlok 1
SKILL.md
