Skip to documentation

Guide · LLM streaming

Available

Test the stream, not just the final text

A client can parse a complete JSON response correctly and still fail on partial UTF-8, event ordering, reconnects, truncation, or a disconnect. Configure those behaviors as fixtures and inspect every frame.

In this guide

  • Exercise HTTP/SSE and WebSocket paths
  • Control TTFT, throughput, chunking, and jitter
  • Model provider event envelopes
  • Prove truncation and disconnect handling

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. Choose the protocol your client actually uses
  2. Stream provider-shaped SSE events
  3. Make timing part of the scenario
  4. Describe WebSocket events directly
  5. Exercise incomplete and invalid streams

Choose the protocol your client actually uses

Use HTTP + SSE for streamed Chat Completions or Responses API calls. Use WebSocket for realtime-style clients and explicit event sequences. A fixture can target http, ws, or both.

Stream provider-shaped SSE events

When the request enables streaming, DotMock renders the matched fixture as the selected provider event format. Configure content, tool calls, finish reason, usage, and streaming timing without hand-writing every data: frame.

bash
curl -N "$DOTMOCK_LLM_URL/v1/responses" \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4.1-mini","input":"Summarize ord_123","stream":true}'

Make timing part of the scenario

Time to first token tests loading states and timeouts. Token rate and chunk size test incremental rendering. Jitter tests consumers that accidentally depend on uniform timing. Keep values explicit when a test asserts elapsed behavior.

  • ttftMs — wait before the first event
  • tps — target token throughput
  • chunkSize — content grouped into each emitted chunk
  • latencyMs — fixed delay between chunks
  • jitter — controlled timing variation

Describe WebSocket events directly

A WebSocket fixture can emit ordered typed events with per-event delays, close normally, close with a chosen code, or disconnect after a duration. Use the raw-frame view to prove event order and terminal behavior.

json
{
  "events": [
    { "type": "response.created", "data": { "id": "resp_test" } },
    { "type": "response.output_text.delta", "data": { "delta": "Ready" }, "delayMs": 40 },
    { "type": "response.completed", "data": { "id": "resp_test" } }
  ],
  "closeAfter": true,
  "closeCode": 1000
}

Exercise incomplete and invalid streams

Truncate after a chosen number of chunks, emit malformed data, drop output, or disconnect. Assert that the application clears loading state, preserves partial content only when intended, and surfaces a useful retry path.