> For the complete documentation index, see [llms.txt](https://docs.nlx.ai/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nlx.ai/platform/nlx-platform-guide/applications/testing.md).
# Testing
## **Testing**
Testing in agentic CX designer lets you validate how your conversational AI application behaves before it is used in a live customer experience.
Use testing to confirm that your application:
* Starts from the expected flow
* Routes user utterances to the correct flows
* Captures slots and variables correctly
* Applies state modifications as expected
* Uses Data requests, knowledge bases, and tools successfully
Agentic CX designer includes several testing tools for different stages of review:
| Testing option | Use |
| -------------------- | ---------------------------------------------------------------------------------------------------- |
| **Application test** | Run an end-to-end test conversation from the application’s starting point. |
| **Flow test** | Test a specific flow in isolation from the Canvas. |
| **Routing tests** | Validate whether different user utterances invoke the expected flows. |
| **Flow logic tests** | Save and replay a sequence of test inputs for repeatable flow testing. |
| **Debugger** | Inspect turn-by-turn events, variables, state, node traversal, and errors during test conversations. |
***
### **Build requirement**
A successful build is required before workspace testing features can run against your application package.
A build packages the current version of your application, including attached flows, routing descriptions, guardrails, slots, languages, and settings. Testing then lets you validate that packaged version before deploying it.
***
### **Application test**
Use an application test when you want to validate the full end-to-end experience. The conversation starts from the flow assigned to the application’s **Welcome** default behavior.
To run an application test:
1. Open **Applications**.
2. Select the application you want to test.
3. Confirm the application has at least one successful build.
4. Select the **Test** tab.
1. Start a new conversation.
2. Type test user messages.
3. Review how the application responds by choosing the Debugger option in the upper right to see turn-by-turn events.
Use this test when you want to experience the application the way a user would from the beginning of a conversation.
***
### **Flow test**
Use a flow test when you want to isolate and troubleshoot a specific flow.
Flow testing opens directly from the Canvas and begins from the first turn of the selected flow instead of the application’s Welcome flow. This is useful when you are building or refining one flow and do not want to start from the full application every time.
To run a flow test:
1. Open **Resources** from the workspace menu.
2. Select **Flows**.
3. Choose the flow you want to test.
4. Select the **Test** icon from the Canvas toolbar.
5. Enter test user responses in the test chat.
6. Refresh the test chat as needed.
The test panel in a flow test includes settings that let you adjust the test session.
Use the settings option (gear icon) when your test requires a specific starting point, context value, language, or environment.
Common settings include:
| Setting | Use |
| --------------------- | -------------------------------------------------------------------------------------------------- |
| **Starting flow** | Change which flow the test initializes from. |
| **Context variables** | Enter values that would normally be set earlier in the conversation or passed from another system. |
| **Language** | Test language-specific behavior, if available. |
| **Environment** | Choose whether Data requests should use Development or Production endpoints, when configured. |
For example, if a troubleshooting flow expects the user to already be authenticated, you can set an **authenticated** context variable before running the test.
After changing test settings, select **Save and refresh** so the updated settings apply to the session.
***
### **Routing tests**
Routing tests validate whether user utterances invoke the expected flows.
Routing tests are located in the application’s **Settings** area under **Testing**. They use the AI descriptions added to flows to evaluate whether a test utterance should match a specific flow.
Use routing tests when you want to confirm that different ways of asking for help route correctly.
Examples:
| Test utterance | Expected flow |
| ---------------------------------- | ----------------------------- |
| “I need to change my appointment.” | Appointment rescheduling |
| “Can I talk to someone?” | Escalation |
| “What are your hours?” | Policy or knowledge base flow |
| “I need help with billing.” | Billing support |
| “Can I check my order?” | Order status |
To create a routing test:
1. Open the application.
2. Select the application **Settings**.
3. Go to the **Testing** section.
4. Under **Routing**, select **New test**.
1. Enter a test name.
2. Add one or more test utterances.
3. Select the expected flow for each utterance.
4. Save the test.
To run a routing test:
1. Open the saved routing test.
2. Select the test execution option.
3. Run the test.
4. Review the results.
5. Compare the expected flow against the actual matched flow.
A failed routing test means the utterance did not match the expected flow. Review the flow’s AI description and routing coverage, then update and test again.
***
### **Flow logic tests**
Flow logic tests let you save and replay a sequence of inputs for repeatable testing.
Use flow logic tests when you want to quickly validate the same path after making changes. This is helpful for regression testing, repeated QA, and confirming that known scenarios still work as expected.
To create a flow logic test:
1. Open a flow from **Resources > Flows**.
2. Select the **Test** icon from the Canvas toolbar.
3. Enter the sequence of user inputs you want to test.
4. Save the input sequence as a new flow logic test by selecting the play icon on the bottom of the test panel:
1. Enter a clear test name.
2. Save the test.
After a flow logic test is saved, you can replay it to confirm the flow still behaves as expected after future changes. Replay a test, bu choosing the play button and the launch play icon on a saved named test.
***
### **Test conversation controls**
Test chats on an application or in a flow include controls that help you repeat or reset test sessions.
| Control | What it does |
| ------------ | ----------------------------------------------------------------------- |
| **Replay** | Reruns the last conversation using the same inputs. |
| **Reset** | Starts the test session over and clears previous inputs. |
| **Debugger** | Opens event details for troubleshooting a selected application message. |
Use **Replay** when you want to quickly retest the same path. Use **Reset** when you need a clean session.
***
### **Debugger**
The debugger helps you inspect what happened during a specific turn in a test conversation.
To open debugger details:
1. Run a test conversation.
2. Select an application message in the transcript or choose the debugger icon on an application test.
3. Review the event list for that turn.
4. Expand events to inspect details.
Use the debugger when the application behaves unexpectedly, such as skipping a question, repeating a message, routing incorrectly, looping, triggering fallback, or failing after a Data request.
***
### **Troubleshooting state and variables**
Many unexpected testing issues are related to state, slots, variables, or agentic or generative node prompts.
When troubleshooting, start with the last successful turn and inspect the events that followed.
If needed, simplify the flow path:
1. Start from the first node in the affected turn.
2. Temporarily disconnect later nodes.
3. Connect the first node to a simple Basic node with a success message.
4. Save and test.
5. If the turn succeeds, reconnect one additional node.
6. Test again.
7. Continue until the turn fails.
The last reconnected node is often where the issue begins.
***
### **Best practices**
* Create a successful build before using application or flow testing.
* Use application tests for end-to-end behavior.
* Use flow tests for focused troubleshooting.
* Use routing tests to validate flow recognition across different utterances.
* Use flow logic tests for repeatable paths and regression testing.
* Set context variables before testing flows that depend on earlier conversation state.
* Test happy paths, unclear inputs, missing information, retries, No match paths, fallback paths, and escalation.
* Use the debugger to inspect unexpected behavior.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.nlx.ai/platform/nlx-platform-guide/applications/testing.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.