---
id: dryrun-request-builder
title: Dryrun request builder
abstract: Add a high-level DryrunRequest builder that wires programs, ledger context, and transactions for the dryrun and dryrun_testing features.
status: accepted
date: 2026-05-18
deciders: []
tags: []
---
# Dryrun request builder
## Status
Accepted
## Context
`tests/features/integration/dryrun.feature`,
`tests/features/integration/dryrun_testing.feature`, and the unit
companion `tests/features/unit/dryrun_trace.feature` use step phrases
that imply a high-level builder:
- `I dryrun a "<kind>" program "<program>"`
- `dryrun test case with "<program>" of type "<kind>"`
- `global delta assert with "<key>", "<value>" and <action> is succeed`
- `local delta assert for "<addr>" of accounts <index> with "<key>", "<value>" and <action> is succeed`
- `status assert of "<status>" is succeed`
- `it is compiled with <status> and "<result>" and "<hash>"`
The autogenerated `DryrunRequest` model exists in
`algonaut_algod/src/models/dryrun_request.rs` but has no companion
builder. Reference SDKs ship a `DryrunRequest::create` (Java) /
`util::build_dryrun` (Go) helper that:
1. Takes a single transaction or group plus a list of `DryrunSource`
programs and bundles them into a `DryrunRequest`.
2. Pre-populates ledger-state plumbing (`accounts`, `apps`, `assets`,
`round`, `protocol-version`, `latest-timestamp`) so the dryrun is
self-contained.
3. Surfaces structured accessors on the response side
(`DryrunTxnResult`, `DryrunState`, opcode trace, scratch / stack
/ state deltas) — these models already exist on our side but lack
ergonomic helpers.
## Decision
1. Add `algonaut_transaction::dryrun` (parallel to the existing
`auction` module) containing:
- `DryrunRequestBuilder` with fluent setters for `txns`, `sources`,
`accounts`, `apps`, `assets`, `round`, `protocol_version`,
`latest_timestamp`.
- `DryrunRequestBuilder::from_signed_txns(&[SignedTransaction])` and
`::from_sources(&[(&str, CompiledTeal)])` convenience entry points.
- Helpers on the response side: `DryrunResponse::txn(i)`,
`DryrunTxnResult::approve_messages()`, `::cost()`, etc.
2. Wire `Algod::teal_dryrun` to accept the builder output directly.
3. Provide a small `DryrunTestCase` helper for unit-style scenarios so
`dryrun_testing.feature` can run without a live algod.
## Consequences
- The three dryrun features become runnable.
- The builder gives downstream users an actual debugging tool — today
you can call `teal_dryrun` but constructing the request is
prohibitively manual.
- One new module, no breaking changes to existing types.