القائمة
Use when writing two or more tests that differ only by inputs or expected outputs — collapse the duplication into parameterized cases.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | parametrize-related-tests |
| description | Use when writing two or more tests that differ only by inputs or expected outputs — collapse the duplication into parameterized cases. |
rstestWhen you'd write two or more test functions that share their body and differ only by inputs/expected values, write a single #[rstest] function with one #[case] per input set:
#[rstest]
#[case::happy("abc", true)]
#[case::empty("", false)]
#[case::too_long(LONG_INPUT, false)]
fn validate_name(#[case] input: &str, #[case] expected: bool) {
assert_eq!(validate(input), expected);
}
This applies especially to "one test per enum variant" patterns and "one test per error condition" patterns.
Copy-pasted test bodies drift — a fix in one case doesn't reach the others. Parameterized cases keep the assertion in one place, name each case in the output, and make a missing case obvious; adding one is a single line.
// Good
#[rstest]
#[case::fungible(Asset::Fungible(make_fungible()), AssetKind::Fungible)]
#[case::nft(Asset::Nft(make_nft()), AssetKind::Nft)]
fn asset_kind(#[case] asset: Asset, #[case] expected: AssetKind) {
assert_eq!(asset.kind(), expected);
}
// Bad: two test functions duplicating the body
#[test]
fn asset_kind_fungible() { assert_eq!(Asset::Fungible(make_fungible()).kind(), AssetKind::Fungible); }
#[test]
fn asset_kind_nft() { assert_eq!(Asset::Nft(make_nft()).kind(), AssetKind::Nft); }
Enforce type-signature conventions for public Miden Assembly (.masm) procedures. Use when adding, editing, or reviewing a `pub proc` signature — parameter and return types, semantic type aliases, struct/array/tuple types, and how the signature maps onto the operand stack and the doc-comment Inputs/Outputs.
Enforce inline commenting conventions for Miden Assembly (.masm) files. Use when editing, reviewing, or creating .masm files.
Enforce doc comment conventions for Miden Assembly (.masm) procedures. Use when editing, reviewing, or creating .masm procedures, especially when documenting inputs, outputs, panic conditions, or invocation types.
Use when writing kernel, account, or note MASM code that reads from or writes to the advice provider (advice stack / advice map) — validate advice data.
Use when writing a Rust test that exercises a failure path or a MASM test that expects a `panic` / `assert` — assert on the specific expected error variant or error code.
Use when writing or reviewing MASM hot paths — prefer the cheaper equivalent instruction: `neq.0` over `gt.0` for non-zero checks, `cdrop` over an `if/else` selecting between two values, `dup.N` over `loc_load` for a value still on the stack, `eqw` over element-wise word comparison, `u32gt`/`u32lt` over generic `gt`/`lt` on known-u32 operands.