Skip to documentation

Guide · LLM fixtures

Available

Turn prompts into repeatable test scenarios

Fixtures are ordered, enabled behaviors. Every trigger on a fixture must match, and the first matching fixture wins, so a test can name exactly which provider-shaped outcome it expects.

In this guide

  • Match stable request signals
  • Model tool and workflow round trips
  • Add stateful sequencing
  • Control latency, truncation, and failure

Prerequisites

  • A DotMock workspace you can access
  • The API ID in $API_ID and its published runtime URL in $MOCK_URL when the example calls the mock
On this page
  1. Match normalized request fields
  2. Return content or a provider error
  3. Model a complete tool workflow
  4. Sequence behavior with shared state
  5. Control timing and reliability

Match normalized request fields

Use provider and endpoint when one workspace serves several client shapes. Add model, user message, system prompt, tool name, temperature, tool-call ID, tool-result presence, or custom field conditions only when they make the scenario meaningfully distinct.

  • All triggers on one fixture must match
  • Enabled fixtures are evaluated in priority order
  • A fixture without a trigger is a broad fallback
  • Keep a single obvious fallback at the end

Return content or a provider error

Direct responses can include assistant content, finish reason, token usage, response ID, and metadata. Error fixtures return an explicit HTTP status, provider-shaped type, and message so retry and fallback logic sees a realistic contract.

json
{
  "content": "Order ord_123 is ready to ship.",
  "finishReason": "stop",
  "usage": {
    "promptTokens": 34,
    "completionTokens": 9
  }
}

Model a complete tool workflow

A tool fixture first returns one or more tool calls with stable IDs and JSON arguments. A follow-up fixture can require the matching tool-call ID or a tool result, then return the final assistant response. This exercises your orchestration code rather than skipping straight to text.

json
{
  "toolCalls": [
    {
      "id": "call_get_order",
      "name": "get_order",
      "arguments": "{\"id\":\"ord_123\"}"
    }
  ],
  "finishReason": "tool_calls"
}

Sequence behavior with shared state

Before and after state actions use the same runtime as REST, GraphQL, and webhook workflows. Increment a per-conversation turn, consume a queue of outcomes, or read a workspace-shared customer record. Keep structured mutations in actions; LLM fixture content is text.

handlebars
Turn {{state.increment "conversation-turns" "$body.metadata.sessionId" 1}}

Control timing and reliability

Set fixed or random latency, time to first token, token rate, jitter, chunk size, and truncation. Chaos controls can probabilistically drop, malform, or disconnect a response when the test intentionally explores resilience.