Applications

Application packaging has a miserable feedback loop. You write a deployment script, push it to a test machine, install it, discover it prompted for something, clean the machine, and start again. The loop is measured in tens of minutes and most of it is waiting.

Worse, "did it work?" usually collapses to a boolean, and a boolean throws away the most useful information a Windows installer gives you.

PEST scans a package library organised producer → software → version, parses each deployment script, renders its actions as editable cards, and then spins up Windows Sandbox, installs the package silently, retrieves the logs and reports pass or fail with the actual reason.

No compiled executable, on purpose

PEST ships as a signed script plus a module, never as an .exe. That is a deployment decision, not a stylistic one: unsigned executables get stopped by SmartScreen, WDAC and AppLocker in exactly the environments this tool is meant to run in, whereas bundled managed DLLs pass. The delivery vector dictated the architecture.

The parser is an AST, not a regex

Script structure is read with PowerShell's own language parser. Regex is banned for anything structural — it cannot tell a command from the same text inside a string or a comment, and being wrong about that means corrupting somebody's deployment script.

Editing is lossless in both directions. The visual editor writes back by rewriting only the source extents it recognises, preserving every other byte — comments, custom logic, variable setup, whitespace. That guarantee is enforced by tests, not by care:

parse(source) -> model -> emit -> parse again
  => the two models must be identical

A verified command catalogue

The catalogue of deployment commands is built from the real toolkit files and official documentation, stored as data. Anything that cannot be verified is flagged and rendered read-only rather than emitted as a plausible guess — a guessed call in a deployment script is a broken install on somebody's machine.

• A package goes from "edited" to "tested in a clean machine" without leaving the window.
• Test history is kept per package with the logs and reason attached.
• Three-pane interface: library tree, editor tabs, run history.
• Wizards for new deployments and new versions; import from existing infrastructure.
• An agentic assist mode with its own runspace, streaming output and an abort button, scoped to the selected package.

35 Pester files and roughly 7,700 lines of tests cover the round-trip guarantee, sandbox orchestration, detection logic and each window's behaviour. For a tool that rewrites other people's deployment scripts, that ratio is the feature.

A frozen window is a defect, not a delay. Everything slow runs in a runspace and marshals back through the dispatcher, because the moment a packaging tool stops repainting, the person using it assumes it has died and kills it mid-write.

The other one: build the test that proves the dangerous property before building the feature that needs it. The round-trip equality test existed before the visual editor was allowed to write anything to disk, which is the only reason the editor was ever trustworthy enough to use.