mirror of
https://github.com/trailofbits/skills.git
synced 2026-09-14 14:28:48 +08:00
4518c6df20
The "Verify patterns" step under No Mutants Generated ran `ls src/**/*.rs` to answer whether source files exist where the include pattern points. Whether `**` recurses depends on the shell: zsh expands it, bash does not unless globstar is set, and the bash 3.2 macOS ships has no globstar option to set. Under bash the glob degrades to `src/*/*.rs`. On a tree holding src/top.rs, src/a/one.rs, src/a/b/two.rs and src/a/b/c/three.rs, find reports four files and the ls form reports one. So the command existed to tell the user their include pattern was fine and instead under-reported the files that matched it, on some machines but not others. The dropped files read as "include pattern doesn't match" — the first entry in the Common causes list directly below it — and send someone off to edit a pattern that was already correct. find behaves identically in every shell and exits 0 when nothing matches rather than erroring. Only the unquoted shell glob changed. The `**` in mewt.toml include values and in quoted `--target 'src/auth/**/*.rs'` arguments is mewt's own glob syntax, expanded by mewt rather than the shell, and is correct as written; the note says so to keep the fix from spreading there. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Mutation Testing — Campaign Configuration (mewt/muton)
Helps configure mewt or muton mutation testing campaigns — scoping targets, tuning timeouts, and optimizing long-running runs so you can execute mewt run or muton run with confidence.
Note
: muton and mewt share identical interfaces but target different languages — mewt for general-purpose languages, muton for TON smart contracts (Tact, Tolk, FunC). All commands and configuration patterns in this plugin apply to both tools. File names change accordingly:
mewt.toml→muton.toml,mewt.sqlite→muton.sqlite.
The plugin ships one skill, mutation-testing, which the triggers below fire. Invoke it
directly with /mutation-testing:mutation-testing.
What It Does
Walks through a 5-phase configuration workflow:
- Initialize and validate targets — run
mewt init, review auto-generated config, fix include/ignore patterns - Generate mutants and assess scope — count mutants, time the test command, estimate campaign duration
- Decide on optimization — choose between full run, targeted components, high/medium severity only, or two-phase campaign
- Validate test command and timeout — verify the command works; set manual timeout for recompilation-heavy languages (Solidity/Foundry, heavy C++)
- Final validation checklist — confirm config, mutant count, target selection, and timeout before running
When to Use
- Setting up a new mutation testing campaign
- Optimizing a campaign that would take too long to run
- Diagnosing why no mutants are generated or why the test command fails
Prerequisites
- mewt v3.0.0+ or muton v3.0.0+ installed
- A test suite runnable from the command line
- Source code in a supported language:
- mewt: Rust, Solidity, Go, TypeScript, JavaScript
- muton: Tact, Tolk, FunC (TON smart contract languages)
Example Usage
User: "Help me set up mewt for this Solidity project"
User: "Configure muton for this FunC codebase"
User: "My mewt campaign would take 30 hours — how do I optimize it?"
→ Guides through configuration, scope assessment, and optimization
References
- mewt GitHub Repository
- Use mutation testing to find the bugs your tests don't catch — Trail of Bits blog post