Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ellomas.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Use Cases

Replay fits into several key workflows for QA engineers and developers.

​
CI Pipeline End-to-End Tests

Replace brittle shell scripts with a declarative workflow that runs in CI. 
# .github/workflows/e2e.yml
name: e2e-auth-flow
config:
  http:
    base_url: https://staging.example.com
steps:
  - name: register-user
    type: http
    request:
      method: POST
      url: /auth/register
      body:
        email: ci-{{ nowUnix }}@test.com
        password: TestPass123
    extract:
      user_id: $.data.user.id
    assert:
      - ["$.status", "eq", 201]

  - name: login
    type: http
    request:
      method: POST
      url: /auth/login
      body:
        email: "{{ email }}"
        password: TestPass123
    extract:
      token: $.data.token
    assert:
      - ["$.data.token", "not_null"]

  - name: verify-profile
    type: http
    request:
      method: GET
      url: /users/{{ user_id }}
      headers:
        Authorization: Bearer {{ token }}
    assert:
      - ["$.data.email", "contains", "@test.com"]
Benefits: No framework dependency, runs in any CI that supports Go, deterministic with fixed seeds.

​
Multi-Environment Smoke Tests

Use the same workflow across dev, staging, and production with config profiles. 
# replay.yaml
config:
  http:
    base_url: http://localhost:3000
  postgres:
    dsn: postgres://localhost:5432/devdb

profiles:
  staging:
    config:
      http:
        base_url: https://staging.example.com
      postgres:
        dsn: postgres://deploy:pass@staging-db:5432/stagingdb
  production:
    config:
      http:
        base_url: https://api.example.com
      postgres:
        dsn: postgres://reader:pass@prod-db:5432/proddb
Run against each environment: 
replay run smoke-test.yaml --profile staging
replay run smoke-test.yaml --profile production

​
Database Setup and Validation

Use Replay to seed test data and verify it was stored correctly. 
name: db-setup-and-verify
config:
  postgres:
    dsn: postgres://postgres:password@localhost:5433/postgres
steps:
  - name: create-table
    type: db
    query: |
      CREATE TABLE IF NOT EXISTS test_orders (
        id SERIAL PRIMARY KEY,
        customer_email TEXT,
        total NUMERIC
      );

  - name: insert-order
    type: db
    query: |
      INSERT INTO test_orders (customer_email, total)
      VALUES ('qa@example.com', 99.99)
      RETURNING id;
    extract:
      order_id: $[0].id

  - name: verify-insert
    type: db
    query: "SELECT * FROM test_orders WHERE id = {{ order_id }}"
    assert:
      - ["$[0].customer_email", "eq", "qa@example.com"]
      - ["$[0].total", "eq", 99.99]

​
Stateful API Journeys

Model a complete user flow across multiple API calls. 
name: ecommerce-checkout
config:
  http:
    base_url: https://api.example.com
steps:
  - name: search-products
    type: http
    request:
      method: GET
      url: /products?category=electronics
    extract:
      product_id: $.data.items[0].id

  - name: add-to-cart
    type: http
    request:
      method: POST
      url: /cart
      body:
        productId: "{{ product_id }}"
        quantity: 1

  - name: checkout
    type: http
    request:
      method: POST
      url: /orders
      body:
        cartId: "{{ cart_id }}"
        paymentMethod: card
    extract:
      order_id: $.data.order.id
    assert:
      - ["$.status", "eq", 201]

  - name: verify-order-in-db
    type: db
    query: "SELECT status FROM orders WHERE id = {{ order_id }}"
    assert:
      - ["$[0].status", "eq", "confirmed"]

​
Load Validation

Run the same workflow with high concurrency to validate system behaviour under load. 
# Validate that auth handles 50 concurrent signups
seq 1 50 | xargs -P50 -I{} replay run signup.yaml
Or use Replay’s built-in concurrency: 
replay run signup.yaml --concurrency 10 --fail-fast

​
Cache Validation with Redis

Test that your caching layer behaves correctly. 
name: cache-test
config:
  redis:
    addr: localhost:6379
steps:
  - name: set-cache
    type: db
    engine: redis
    command: ["SET", "user:42:profile", '{"name": "Alice"}']
    assert:
      - ["$", "eq", "OK"]

  - name: get-cache
    type: db
    engine: redis
    command: ["GET", "user:42:profile"]
    extract:
      cached_profile: $
    assert:
      - ["$.name", "eq", "Alice"]

  - name: delete-cache
    type: db
    engine: redis
    command: ["DEL", "user:42:profile"]

​
Regression Testing after Migrations

After a schema migration, re-run existing workflows to verify nothing broke. 
# Step 1: Run migration
migrate -database $DATABASE_URL -path migrations up

# Step 2: Run all regression workflows
replay run tests/regression/*.yaml --concurrency 4 --fail-fast

​
Post-Deployment Verification

Trigger a Replay workflow in your CD pipeline to verify the deployment succeeded. 
# .github/workflows/deploy.yml
- name: Smoke test
  run: |
    replay run smoke-tests.yaml \
      --profile production \
      --concurrency 3 \
      --fail-fast

​
What’s Next?