> For the complete documentation index, see [llms.txt](https://docs.decisionrules.io/doc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decisionrules.io/doc/rules/common-rule-features/test-bench.md).
# Test Bench
The Test Bench is a built-in testing environment that allows you to evaluate and validate your rules before deploying them to production. By entering input data and simulating rule execution, you can verify that your rules produce the expected outputs and identify any issues early in the development process.
{% hint style="info" %}
In this guideline you need to have knowledge of [Decision Table](/doc/rules/decision-table.md) and [Decision Tree](/doc/rules/decision-tree.md).
{% endhint %}
### **Why Use Test Bench**
* **Validate logic** - Ensure rules work correctly before deployment.
* **Test edge cases** - Verify behavior with different input scenarios.
* **Debug issues** - Identify and fix problems during development with [Debug Mode](#debug-mode).
* **View detailed execution** - See exactly which rows or branches executed.
* **Iterate quickly** - Make changes and test immediately.
## Accessing Test Bench
Test Bench is available for all rule types and provides a consistent testing experience across them.
**To open Test Bench:**
1. Navigate to any rule in the designer.
2. Click to open the **Test Bench** in the bottom bar.
## Running a Rule
The controls between Input and Output decide how the rule runs:
* **Run** – Evaluates the rule with the current input. The output appears on the right, with the execution time above it.
* **Strategy** – The execution strategy, shown below Run (for example *Standard*). Click it to change. See [Execution Strategy](/doc/rules/common-rule-features/execution-strategy.md).
* **Debug** – Shows how the input was evaluated.
* **Saving a Test** – Saves the current input and output as a test.
* **Run Options** – Additional settings at the bottom of the panel.
## Test Bench Modes
Test Bench offers two interface modes to accommodate different user preferences and use cases:
### **1. Simple Bench**
A simplified interface that displays input (left side of bench) and output (right side of bench) fields as individual form fields, making it easy to test rules without JSON knowledge.
**Best for:**
* Users unfamiliar with JSON.
* Quick testing with simple inputs.
* Clear visualization of individual fields.
{% hint style="info" %}
Commas create arrays (e.g., `1,2,3` becomes `[1, 2, 3]`). To use a comma inside a value, wrap it in quotes: `"some,text"`.
{% endhint %}
#### Date Input **in Simple Bench**
Simple Bench provides a convenient date picker for date fields:
1. Click the **three dots** next to the field.
2. Click the **calendar icon**.
3. Select:
* **Date** (day, month, year)
* **Time** (hours, minutes)
* **Time zone**
4. Click **Save**.
### 2. JSON Bench
A JSON editor interface for entering input and viewing output in standard JSON format.
**Best for:**
* Technical users comfortable with JSON.
* Complex nested data structures.
* Arrays of objects.
* Copy/paste from API responses.
* Precise control over data structure.
### **Switching Between Modes**
**Data Persistence:**
* Input data is preserved when switching between Simple and JSON Bench.
* You won't lose your test data when changing views.
#### **Understanding Display Limitations in Simple Bench**
While Simple Bench is convenient for basic testing, it has limitations when handling complex nested structures. Here are important behaviors to be aware of:
**1. Objects Without Defined Children**
If your input model defines a parent object without specifying its children structure (as an empty object `{}`), and you provide actual nested data in JSON Bench, Simple Bench will display this as `[object Object]`.
```json
// Input Model
{
"action": {
"transaction": {} // Empty object - no children defined
}
}
```
```json
// Actual JSON Input
{
"action": {
"transaction": { // last children based on input model
"transactionValue": 10000,
"transactionCurrency": "USD",
"transactionValueEurEquivalent": 9500
}
}
}
// Simple Bench Display:
action.transaction: [object Object]
```
**What this means:**
* The model doesn't define what children `transaction` should have.
* Simple Bench can't break it down into individual fields.
* Display shows `[object Object]` as a placeholder.
**It still works:**
* The rule receives and processes the complete nested data correctly.
* This is only a display limitation in Simple Bench.
* Use JSON Bench to see and edit the full structure.
2. **Arrays of Objects**
Arrays of objects behave differently depending on whether they're in input or output fields.
* **Input Fields:**\
Not Practical in Simple Bench. Arrays of objects in input fields display as `[object Object], [object Object], [object Object]...`, which doesn't allow you to see or edit the actual data.
```json
// Input Model
{
"factorList": {} // Empty object - no children defined
}
```
```json
// Actual JSON Input
{
"factorList": [
{ "destinationRisk": 0, "historyRisk": 0 },
{ "destinationRisk": 1000, "historyRisk": 1000 }
]
}
// Simple Bench Display:
factorList: [object Object], [object Object]
```
{% hint style="success" %}
Use **JSON Bench** for inputs containing arrays of objects.
{% endhint %}
* **Output Fields:**\
Arrays of objects in output fields show a **View** button that opens a detail modal.
```json
// Output Model
{
"factorList": {} // Empty object - no children defined
}
```
```json
// Actual JSON Output
{
"factorList": [
{ "destinationRisk": 0, "historyRisk": 0 },
{ "destinationRisk": 1000, "historyRisk": 1000 }
]
}
// Simple Bench Display:
factorList: View
```
**Viewing Details:**
1. Click the **View** button
2. A **Detail View** modal opens
3. See the complete structure:
* Each array element numbered (0, 1, 2...)
* All properties displayed with formatting
* Collapsible structure for navigation
## Execution Modes
Test Bench supports different execution modes depending on the rule type and your testing needs. For detailed information about execution strategies and modes, see [Execution Strategy](/doc/rules/common-rule-features/execution-strategy.md).
## Debug Mode
Debug Mode provides detailed execution information, helping you understand exactly how your rule processes data and where issues might occur.
Debug Mode is available for **Decision Tables** and **Decision Trees** only.
### How to Enable Debug Mode
1. Open Test Bench.
2. Look for the **Debug** toggle/checkbox.
3. Enable it (toggle to ON/checked state).
4. Click **Run** to execute with debug information.
### Debug Decision Table
When Debug Mode is enabled for Decision Table, you get detailed visual feedback showing exactly how your input data matches against each condition.
#### **Visual Indicators**
**Row Highlighting:**
* The executed row(s) are visually highlighted in the table.
Shows which rows matched your input conditions.
**Cell-Level Feedback:**
* **Green cells** - Condition **passed** (evaluated to true).
* **Red cells** - Condition **failed** (evaluated to false).
This allows you to see exactly which condition caused a row to pass or fail.
**Value Display:**
* Each condition cell shows the **actual value** being compared.
You can see what the rule is evaluating against your input.
### Debug Decision Tree
When Debug Mode is enabled for Decision Trees, you can trace the execution path through the tree structure and see exactly which conditions were evaluated and which branch was taken.
#### **Visual Indicators**
**Block Highlighting:**
* **Colored borders** show which nodes were evaluated during execution.
* **Green-highlighted blocks** indicate the path that was taken and executed.
* **Red-highlighted blocks** indicate the path that was not taken.
Shows the decision flow from top to bottom through your tree.
**Value Display:**
* Condition blocks show the actual values being compared.
## Saving a Test
Once a rule returns the output you expect, save it as a test so you can rerun the same check after every change.
1. Enter the input and click **Run**.
2. Next to **Test**, click **Save as Test**.
3. Choose the Test Suite and enter a test name. If the rule has no Test Suite yet, enter a name for a new one and it is created together with the test.
4. Click **Save**.
The test stores the current input, the output as the expected output, and the execution strategy. You can view and edit it in the rule's **Tests** tab.
**When the input matches a saved test**
If the input in Test Bench matches a test you already saved, **Save as Test** is replaced by the test's result:
* **PASSED** – The output matches the test's expected output.
* **FAILED** – The output differs. You can update the test to accept the new output.
Click the arrow icon next to the result to open that test in the **Tests** tab.
{% hint style="info" %}
A test does not store a solver version. The same test can be run on any version the space offers. You choose the version when you run it.
{% endhint %}
## Run Options
**Run Options** at the bottom of the Test Bench panel holds additional settings for the run. It is collapsed by default. Click it to expand.
#### **Solver Version**
Choose which solver version runs the rule. The versions offered are the ones enabled in the [space's Run Solver versions settings](/doc/space/settings.md#available-run-solver-versions-in-the-app).
If the space has only one version, there is nothing to choose, and every run uses that version.
{% hint style="info" %}
**The choice applies only to runs in Test Bench.** It does not change the space settings or the version your API calls use.
{% endhint %}
**Rule Flows** and **AI Agents** always run on V1, whichever version you choose. See [Exceptions](/doc/api/rule-solver-api/rule-solver-api.md#exceptions).
---
# 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.decisionrules.io/doc/rules/common-rule-features/test-bench.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.
.png?alt=media&token=409fcdde-bd72-4e1a-a05e-c8787a63b3ba)
