Understanding Test Contexts

getTestContexts() returns a stream of TestContext updates for the traces in the currently configured test. The first values you receive give you a complete set of contexts for the configured traces, and later values let you observe how those contexts change over time.

Each TestContext identifies a trace by traceIndex and carries that trace’s current TraceContext.

Trace contexts also include the current calibration status for the trace. Depending on the trace type, they may also include related information such as the last calibration time or when calibration is next due.

Why test contexts are streamed

Trace readiness can change while your app is running. A trace might become runnable after an instrument connects, or it might stop being runnable if the device reports a new problem.

That is why test contexts are exposed as a stream instead of a one-shot result: they represent current runtime state, not just configuration-time state.

Understand blockers

The most important part of a trace context is its blocker list.

Each concrete trace-context type has its own blockers property. A trace will only run when that list is empty.

If the blocker list is not empty, the trace is not runnable yet. That does not always mean the test is permanently invalid. It often means your app needs to wait for, fix, or communicate some current condition first.

Some examples include:

• instrumentNotConnected
• batteryLow
• rtfNotZeroed

In practice, the blocker list is the quickest way to answer the question, “Can this trace run right now?”

Use the stream in your app

Applications typically consume getTestContexts() to keep UI or workflow state aligned with trace readiness.

For example, you might show blockers in the UI, disable a “Run Test” action while any trace still has blockers, or prompt the user to connect an instrument before trying again.

C#

await foreach (var context in unify.GetTestContexts())
{
    Console.WriteLine($"Trace {context.TraceIndex} updated: {context.TraceContext}");
}

Kotlin

unify.getTestContexts().collect { context ->
    println("Trace ${context.traceIndex} updated: ${context.traceContext}")
}

Swift

for try await context in unify.getTestContexts() {
    print("Trace \(context.traceIndex) updated: \(context.traceContext)")
}

The exact blocker list depends on the concrete trace type, so apps usually inspect the specific trace context they care about and then read its blockers property.

Relationship to test configuration

When you call configureTest(test:), the returned TestConfigurationResult includes initial trace contexts for the configured test.

Use those initial contexts as the starting snapshot, then use getTestContexts() to observe ongoing updates after configuration.