Test across services

Varianz tests are not bound to one process. A single test session can override a VPoint in one service, probe a VPoint in another, and trigger the flow through a third — because all services share the same registry and the session ID travels with the request.

The pattern

Override or probe the downstream services you need to control or observe.
Sync, so every connected service has the stages.
Trigger the flow through the entry point — an HTTP call or gRPC request carrying x-varianz-id. The ID propagates hop by hop.
Assert on the response and on captured samples.

from datetime import timedelta
from varianz import cel

def test_checkout_sends_notification(varianz):
    # Probe the notification service (it might be Go; the test doesn't care)
    varianz.insert(cel("notification/send", 'sample("notification-sent", invoke())'))
    varianz.await_sync_or_fail(timeout_ms=5000)

    # Trigger via the entry point; the session ID flows downstream
    resp = requests.post(
        "http://localhost:8080/api/order",
        headers={"x-varianz-id": varianz.session_id},
        json=order_payload,
    )
    assert resp.status_code == 200

    varianz.assert_sample("notification-sent") \
        .within(timedelta(seconds=10)) \
        .exists()

Add an override on payment/charge and a negative assertion on the probe, and the same shape tests the failure path — see Override and observe.

When triggering over HTTP from Python, use a requests.Session() with the header set on the session object. Bare requests.post(headers=...) drops custom headers when following redirects, which silently strips the session ID.

The test language doesn’t have to match the service language

The protocol between every test SDK and the registry is identical: stages go in via gRPC with the session ID; samples come back the same way regardless of which runtime executed the VPoint. Pick the test harness that fits your team:

Test harness	Can drive services written in
`varianz-pytest` (Python)	Python, TypeScript, Go, Java, Kotlin — any instrumented service
JUnit 5 extension (Java/Kotlin)	any instrumented service
`varianztest` (Go)	any instrumented service
`@varianz/vitest` (TypeScript)	any instrumented service
`@varianz/playwright` (TypeScript)	any service reachable over HTTP, driving a real browser

This is useful in practice: drive a Java service from pytest without standing up a Gradle test project; probe a Go service from the Python suite that already covers the flow; keep browser tests in Playwright while the backend stages live wherever they live.

Services without an SDK

Services in languages without a Varianz SDK (C#, PHP, Elixir, …) can’t host VPoints, but they don’t break the pattern:

Instrument the services they call.
Trigger the uninstrumented service through its normal API.
Override and probe the instrumented services downstream of it.

The only requirement: the uninstrumented service must forward the x-varianz-id header to its downstream calls, or the session chain breaks at that hop. That’s usually a one-line addition to an existing header-forwarding list — see Propagate sessions.

Targeting when names collide

If two services register VPoints with the same short name, or you run the same service in several environments, scope the stage’s routing target:

# Only checkout-service instances, only us-east-1 prod:
varianz.insert(cel(
    "checkout-service:payment/charge region=us-east-1 cluster=prod",
    'ChargeResult { declined: true }',
))

Targets match VPoint names by suffix on / boundaries and must resolve to exactly one VPoint — ambiguity is an error, and adding segments (or org=/pkg= filters) disambiguates. Full rules: Naming and routing.

Getting started

Core concepts

Guides

SDK reference

Testing

Reference

Test across services

The pattern

The test language doesn’t have to match the service language

Services without an SDK

Targeting when names collide

​The pattern

​The test language doesn’t have to match the service language

​Services without an SDK

​Targeting when names collide

The pattern

The test language doesn’t have to match the service language

Services without an SDK

Targeting when names collide