Skip to main content
Limited Release. The EDK is currently in limited release and is not available to all customers. Commands, generated file layouts, and package APIs may change before general availability. Confirm you’re on the latest EDK version before starting new projects.
User acceptance testing verifies that a deployed solution produces the required business outcome. A successful command or plausible agent response is not enough: persisted records, files, automation executions, tool calls, and user-visible results must agree. The examples use the active profile. See Authentication if you need to select a different or ambiguous target. Use the /elementum-uat coding-agent playbook when you want an assistant to execute and document this workflow. See Playbooks.

​
Define the Test Contract

Before creating test data:
  1. Confirm the profile, organization, App namespaces, test users, and permitted side effects.
  2. Turn each requirement into a test with setup, action, expected observable result, and cleanup.
  3. Identify every applicable layer: records, files, automations, agents, tools, conversations, integrations, and the final outcome.
  4. Give test records and files a unique run prefix, such as UAT-20260818-01.
  5. Decide whether cleanup is approved. Never delete data the test did not create.
Check the target before continuing:
Stop if the profile or App differs from the agreed target. Do not run tests that mutate production data without explicit approval.

​
Use a Practical Test Sequence

Test from the lowest layer upward. This makes failures easier to locate and prevents an end-to-end test from hiding a basic data or deployment problem.

​
1. Verify records and validation

Preview record creation, then create and read back a uniquely named fixture:
Exercise required updates, filters, status changes, relationships, and validation failures. Assert the stored field values after each operation. A zero exit code confirms that the request completed, not that the resulting record is correct.

​
2. Verify files

When the solution accepts files, use a representative fixture with the expected type and realistic content:
Read the record back and confirm the attachment is present. Then verify any downstream extraction, classification, automation, or agent behavior that depends on the file. Include unsupported type, empty file, large file, or malformed-content cases when the requirements define how they should behave.

​
3. Verify automations

Trigger each automation through its real entry point, such as record creation, record update, an approved on-demand action, or a supported webhook. Inspect the resulting execution:
Verify:
  • The intended trigger selected the execution.
  • Tasks ran in the expected order.
  • Each task received the correct inputs and returned the expected outputs.
  • Record changes and external effects occurred exactly once.
  • Failure and retry behavior matches the acceptance criteria.
  • The final business result is correct.

​
4. Verify agents and tools

Test an agent with direct requests, missing-information prompts, confirmation or refusal gates, tool selection, multi-turn context, and error recovery:
For file-aware behavior, attach the same type of fixture used by the real process:
For every expected tool call, confirm the selected tool, inputs, result, and resulting record, automation, or external effect. If the agent can access packaged capabilities or delegate to another agent, verify routing and the delegated result independently. Do not infer tool correctness from the final message alone.

​
5. Run the end-to-end journey

Run at least one realistic journey across all participating components:
  1. Create the initial record or submit the entry action.
  2. Attach or generate required files.
  3. Complete each user decision or stage transition.
  4. Observe automation execution and external effects.
  5. Exercise the agent and verify its tool calls where applicable.
  6. Read back the final records.
  7. Confirm the user-visible business outcome.
Use the unique prefix to find the final fixtures:
Pass the journey only when the visible result, stored data, files, executions, conversations, tool calls, and required external effects all match the acceptance criteria.

​
Record Evidence

For each test, record:
  • Test ID and requirement.
  • Fixture and setup.
  • Commands or user actions.
  • Expected and actual results.
  • Record handles, execution identifiers, conversation identifiers, and relevant screenshots.
  • PASS, FAIL, or BLOCKED.
  • Cleanup status.
Use FAIL when the product behavior contradicts the acceptance criterion. Use BLOCKED when the environment, permissions, unavailable dependency, or invalid fixture prevented the test from reaching the behavior under review.

​
Clean Up Safely

Delete only fixtures created by the current run, and only when cleanup was approved:
Record any fixture that could not be removed so the environment owner can review it.