> ## Documentation Index > Fetch the complete documentation index at: https://docs.heylua.ai/llms.txt > Use this file to discover all available pages before exploring further. # lua test > Run a tool, webhook, job, processor, or workflow locally with the input you give it `lua test` compiles the project and executes one primitive in a local sandbox with your input. No model is involved, so the output is exactly what your code returns. Nothing is pushed and nothing changes for end users. *Verified against lua-cli 3.33.0.* ## Synopsis ```bash theme={null} lua test --name [--input ] [--json] lua test workflow --name [--input |@] [--json] [workflow flags] ``` ## Description The command compiles locally, loads the artifact, and runs it. Your code runs for real: calls to `Data`, `User`, `Products`, `Jobs`, `Workflows`, and the other runtime objects reach the platform with your credential and the project's agent, so a tool that writes data writes it. Secrets come from the shell environment and the project's `.env`, which `env('KEY')` reads. Tools see the request channel `dev`. Local runs only. `lua test` executes the SDK's typed behavior, so `Data.create(…, { index })`, `Data.collections()`, and `Voice.createSession` work here but are not accepted by the deployed runtime yet. Without a type the command prompts; `--name` without a type exits 2. Pass both in automation and add `--ci` so any remaining prompt fails instead of waiting. `lua test skill` without `--name` opens a tool picker that `--ci` does not intercept (with stdin closed the command ends with exit 0 and runs nothing), so always pass `--name`. `--name` is the entity's name, and for `skill` that is the tool's `name` field (`lookup_tickets`), not the skill's. `--input` is a JSON string whose shape depends on the type; without it the command prompts, an empty answer means `{}`, and under `--ci` the prompt exits 1 with `Interactive prompt required but --ci flag is set`, so pass `--input '{}'` for a tool that takes no fields: | Type | `--name` | `--input` | | --------------- | -------------- | --------------------------------------------------------------------------- | | `skill` | tool name | The tool's input object, for example `{"customerEmail":"user@example.com"}` | | `webhook` | webhook name | `{"query":{},"headers":{},"body":{}}`; a missing part defaults to `{}` | | `job` | job name | Not used; the job runs once, now, regardless of its schedule | | `preprocessor` | processor name | `{"message":"…","channel":"web"}` | | `postprocessor` | processor name | `{"message":"…","response":"…","channel":"web"}` | | `workflow` | workflow name | The run input; `@path.json` reads a file | Plural forms, and `tool` for `skill`, are accepted. If `execute` throws, the run still completes: the result is `{ status: 'error', error: '' }` and the exit code is 0, so scripts must read the `status` field. Text output prints a shape line such as `Tool returned: Array[3] of DataEntryInstance — fields: id, data, …` and then the value. `--json` prints only the returned value as JSON on stdout and routes progress to stderr, so `lua test … --json | jq` works. ### Workflows `lua test workflow` runs the [workflow](/concepts/workflows) through the offline driver: code steps execute your code, agent steps return fake output unless `--agents live`, approvals and signals are answered from flags or prompts, and timers are fast-forwarded. Its compile skips server reconciliation, so nothing is registered on the agent. `--step-output`, `--approve`, `--deny`, and `--park` take the step id from your `createStep` or `.approval()` call (a foreach child such as `review[2]` falls back to its base id), never the `wfa_` approval id that `lua workflows approve --approval` takes. An approval, signal, or resume with no flag answer is prompted for in a terminal; with stdin closed or under `--json` it exits 2 with `APPROVAL_UNANSWERED`, `SIGNAL_UNANSWERED`, or `RESUME_UNANSWERED`, and under `--ci` in a terminal the prompt exits 1. `--json` prints `{ "success": , "data": { "status", "output", "exitCode", "error", "ledger" } }` on stdout, where `status` is `completed`, `failed`, or `cancelled`, `error` is `{ code, message, stepId }` when present, and the compile chrome goes to stderr. The same flags work on `lua workflows run`, which also accepts `--env KEY=value` for a local `env.template()` overlay. See [Test workflows offline](/build/workflows/test-offline). ## Arguments | Argument | Values | Description | | -------- | ---------------------------------------------------------------------- | --------------------------------------------- | | `type` | `skill`, `webhook`, `job`, `preprocessor`, `postprocessor`, `workflow` | Prompted when omitted; required with `--name` | ## Options | Option | Description | Default | | ---------------- | --------------------------------------------------------------------------- | --------------------------------------------- | | `--name ` | Entity to run; the tool name for `skill`. The `skill` picker ignores `--ci` | prompt | | `--input ` | Input in the shape the type table gives; workflows also accept `@file` | prompt, blank means `{}`; under `--ci` exit 1 | | `--json` | Print only the result as JSON on stdout | formatted | Workflow flags: | Option | Description | Default | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------ | | `--step-output ` | Complete a step with this output instead of running it; repeatable, `@file` allowed. Script form: `