Tests for Application-Facing Workflows

Application-facing workflows use the application message hint to select the relevant route:

{{ $context.$app.$OraMessageHint }}

Keep stage-specific behavior in distinct branches or terminal nodes.

Application Stages

Each application stage uses a specific entry point and requires validation of the corresponding response or behavior. Use the following guidelines to identify the appropriate entry point and validation requirements for each stage:

Application Stages

Application behavior	Runtime hint	What the test should verify
Focused panel	AdditionalContent	Correct OraPanelName branch and content
Communication preparation	FillParameters	Required editable values are prepared
Startup suggestions	InitActions, InitCommunications	Required suggestion response contract
Startup display	InitDisplay	Correct route and valid oraInfoDisplay response
Dynamic starter queries	InitSampleQueries	Strict starter-query JSON
Application action	InvokeAction	Action payload selects the intended follow-up
Ask Oracle answer	Query	Appropriate use of user and application context
Query filter values	QueryFilterValues	A JSON array of display strings
Communication send or create preparation	SendCommunication	Body and user-reviewable values are prepared correctly

Use OraAppDisplayDiscriminator to distinguish between shared top-level startup panels and OraPanelName to identify the appropriate AdditionalContent panel. Include only the context required for the selected application stage.

Strict Response Contracts

Each application entry point must follow a specific response contract to ensure that the output contains the required structure and values. Use the following guidelines to validate the response contract for each entry point:

• InitSampleQueries: Starter-query JSON only; no Markdown fences, oraInfoDisplay, actions, or communications. Return {} when no suggestions are available.
• QueryFilterValues: A JSON array containing display strings only.
• SendCommunication: Communication body in content; user-reviewable values such as recipient and subject in params.

Test FillParameters and SendCommunication separately.

Application Panels and Backing Workflows

Application panels and their backing workflows require separate tests to validate workflow behavior, panel connections, and response structures. Use the following guidelines to determine the validation scope for each test type:

• Workflow test: Tests routes, data use, transformations, application stages, and response quality.
• Application panel test: Tests top-level panel-to-workflow connections and returned widget structures.

Complete required backing-workflow coverage before application-panel synchronization. Each testable top-level panel requires startup coverage.

Panel tests validate functional contracts. They don’t click controls or certify browser appearance. Use the following prompts with your coding assistant:

Generate and run tests for <app name> and its backing workflows.Complete required workflow coverage, validate the top-level panels, and show the consolidated report.

Tests for Multiturn Conversations, Human Interactions, Waits, and Loops

Use a conversation test when a single request can't fully validate the behavior. A conversation consists of at least two ordered chats or resume-steps that share a runtime state, allowing subsequent requests to reference information provided earlier in the conversation. Internal prompts and assertions must remain separate from runtime chat messages.

• Conversation variable: A later route uses an earlier stored value.
• Cached data: Follow-ups reuse data; refresh or clear operations invalidate it appropriately.
• Human decision: The run suspends and resumes after a supported response.
• Scheduled wait: The run resumes through the timeout path.

One conversation counts as one suite case. Its report includes the transcript, per-step route evidence, assertions, judging, replay data, and available metrics. ATLAS preserves exact user-supplied messages.

Human and Wait Support

• HUMAN: Approval, rejection, or feedback enabled by a root CHAT workflow
• WAIT: Timeout continuation without waiting for the configured wall-clock duration

Limitations:

• HUMAN email interactions and APPROVAL_PROCESS aren't covered.
• HUMAN or WAIT inside LOOP, WHILE, PARALLEL, or nested-workflow jobs aren’t covered.
• Application panel tests don’t author these interactions.
• Runtime callback credentials and job identifiers must not be stored in tests.

Loop Coverage

• loop-boundary: Downstream consumption of the complete recorded LOOP result. The LOOP body isn’t rerun during file replay.
• loop-internals: One coherent representative iteration, including internal routes, supported recorded data, semantic nodes, and downstream consumers.

Cover meaningful internal branch outcomes without multiplying every LOOP path by every application stage.