ATLAS: Test data, how it’s recorded and how to bring your own

Blog 6 · Hands-on

Every test carries the data it needs. Here’s how that data gets into a test, what it looks like in the file, and the three ways you can supply your own values.

How recording works

If a real response is too big to store, the assistant trims it: it keeps two to five representative real rows and only the fields the workflow reads in its prompts, code, checks, and judge rubric, then fixes the record counts to match. If Fusion itself cut the response short during the run, ATLAS won’t save the partial data. It asks you to reduce the data in the test environment or increase the debug size instead.

What it looks like in the test file

These excerpts come from the Team Health workflow’s tests. Values are shortened.

"testData": {
  "status": "ready",
  "capturePolicy": "record-now",
  "nodes": {
    "GET_MANAGER_ASSIGNMENT": {
      "nodeType": "BO_FUNCTION",
      "capture": { "mode": "raw" },
      "response": {
        "count": 1, "hasMore": false,
        "items": [{ "AssignmentId": "3000…",
                    "PersonId": "3000…" }]
      } } } }

"testData": {
  "status": "ready",
  "capturePolicy": "model-generated",
  "generationPrompt": "…returns the exact
    no-manager-assignment message…",
  "nodes": {
    "GET_MANAGER_ASSIGNMENT": {
      "capture": { "mode": "model-generated" },
      "response": {
        "count": 0, "hasMore": false,
        "items": []
      } } } }

The second test needs no special environment: an empty response from the assignment lookup is all it takes to send the workflow down its “no manager” path. That is how fallbacks get tested reliably.

Four ways data gets into a test

Bring your own data

You can supply your own values at three levels. Whatever you provide takes priority over anything ATLAS would choose, and it’s kept on future syncs.

• 1 · Inputs · The request itself: An exact chat message, REST parameters, record IDs, app context, or extra chat context. Messages you write are kept word for word.
• 2 · Records · What gets recorded: Point the test at specific safe records in a test environment: a known manager, order, or opportunity.
• 3 · Responses · What a step returns: Describe or paste the response one step should return. Only the steps that steer the branch change; the rest of the recording stays real.

Run the sync plan for Requisition Details. For InitDisplay, use OraAppContext with requisitionId 300100681458328 and issue Stagnant, then record and preserve that input on later syncs.

Create tests for the revenue update and delete paths. Use this safe test opportunity number and revenue record ID. Do not use production data. Run the focused suite and summarize the results.

Show which recordable step's data controls the no-ratings branch. Keep the rest of the recording, and make only that step return an empty list of ratings.

"testDataOverrides": {
  "GET_TEAM_PERFORMANCE_RATINGS": { "response": { "items": [] } }
},
"pathAssertions": {
  "mustExecute":    ["GET_TEAM_PERFORMANCE_RATINGS", "NO_RATINGS_RETURN"],
  "mustNotExecute": ["BUILD_TEAM_PERFORMANCE_DASHBOARD"]
},
"assertions": { "equals": "No team performance ratings found for the selected period." }

What a replay does and doesn’t prove

• It doesn’t recheck the live connection: A recorded-data run proves the agent behaves on known data. It doesn’t prove the Business Object, REST service or retrieval still answers today. Keep a live run in your routine for that.
• A missing response stops the run: If a test needs a saved response it doesn’t have, the replay stops before that data call instead of quietly reaching out to Fusion. Record the missing data or generate it.
• A replayed child is a boundary: When a parent replays the result of a child workflow or a whole loop, the parent’s test doesn’t exercise what happens inside. Give the child, or one representative pass through the loop, its own tests. In Blog 8, the Person Data Assistant is that kind of boundary.
• Trimmed data must still add up: If a team of 12 is cut to 3 to keep a test small, every related response has to agree: the same IDs, counts that match, child records that belong to those 3, and loop inputs for exactly 3. Otherwise the model is reasoning over a story that contradicts itself.

Keep it safe

• Nonproduction for writes: Recording runs the workflow for real. Anything that creates, updates, deletes, or sends should be recorded in a test environment with safe records, and the assistant asks before it changes data. Replays never repeat the action.
• No secrets in tests: Test inputs and data are committed to source control. Use sanitized or synthetic identifiers, never passwords or tokens.
• Mask sensitive fields: Name the fields, and ATLAS replaces each value with a consistent stand-in across every related test, so joins and routes still work.

Create a reusable HCM masking profile for PersonId, employee names, and email addresses. Apply it to future recordings and validate file replay.

When the data is the problem