Generating Pester tests

Test generation is usually where teams learn to distrust generated code, because most generators invent plausible assertions and produce green suites that verify nothing. DetentShell’s generator refuses to guess: structure it can derive becomes assertions, intent it can’t know becomes clearly labeled pending stubs. The tally your team sees is honest, which is the property that makes generated tests worth adopting.

Tools > Generate Pester Tests targets the function at the caret; ambiguous files raise a picker. The generated tab carries a banner with a testability score, the placeholder count, and a Next-placeholder button that walks the FILL IN stubs. The Pester panel runs the loop: Run these tests executes with your installed Pester (v5+), pending never counts as passing; Save test writes to Tests\Unit\<Function>.Tests.ps1 under the project root; Refresh coverage audits which functions lack tests; Generate for all missing batches the gap. Generated files parameterize their project root, so they run the same unsaved, saved, or in CI. Saved files are plain Pester — Invoke-Pester runs them anywhere.

For a hands-on walkthrough, see the generate your first tests tutorial.

Tests are little scripts that check your script still works. Writing them from scratch is the hard part, so DetentShell writes the skeleton for you: open your script, put your cursor in a function, and pick Generate Pester Tests from the Tools menu. The file that appears already checks the basics, and everywhere it needs a fact only you know — what the function should return for a given input — it says FILL IN. Fill one in, click Run these tests, and watch the pending number go down.

Generated tests never fabricate assertions: unverifiable expectations are marked pending and stay pending until a human supplies the fact. Test results reported by the panel match Pester’s own tally.