> 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/space/tests.md).

# Tests

Rule Testing lets you verify rule behavior against saved scenarios using fixed inputs and expected outputs. Use the Test Bench for quick, ad-hoc checks while editing.

#### Why Use It?

* Validate changes before releasing to production.
* Catch side effects and broken logic early.
* Recheck rules automatically after platform updates.
* Understand rules faster through real-world input/output examples.
* Compare results between solver versions before switching.

#### Core Concepts

* Test: A single scenario (Input + Expected Output). You can choose to ignore dynamic values (like generated timestamps) so they don't cause false failures.
* Test Suite: A folder that groups related tests together. It is strictly linked to a specific rule version.
* Test Run: The execution record of your tests (Passed, Failed, Error, or Canceled).

#### Two Ways to Manage Tests

1. Rule-Level (Inside a rule): Create, edit, and debug tests for the specific rule you are actively working on.
2. Space-Level (Main menu): Manage bulk actions, move tests between rules, and view execution history across your entire space.

The interface is divided into two main tabs: [**Tests** ](/doc/space/tests/tests-tab.md)and [**Test Runs**](/doc/space/tests/test-runs-tab.md)**.**

### API Automation

Rule Testing can be fully automated via the DecisionRules API, making it easy to integrate testing directly into your CI/CD pipelines or external systems.

Authentication To authenticate requests, use a Bearer token with a valid Solver API key: `Authorization: Bearer YOUR_SOLVER_API_KEY`

Key Endpoints

* Start a Test Run (`POST /testRun/start`): Starts a new execution job. You must provide an array of `testSuiteIds` and/or `testIds` in the JSON body. The response returns a `testRunId`.
* Get Test Run Job (`GET /testRun/{testRunId}`): Retrieves the overall execution state, timing context, and results of a specific test run.

More info [here](/doc/api/rule-testing-api.md).

<figure><img src="https://437457296-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MN4F4-qybg8XDATvios%2Fuploads%2F57IJLfKsmSFmyjYzPabQ%2Fchrome_7JaKdgmfJz.png?alt=media&amp;token=bc39a9f4-41a8-46a0-9b64-7df85d077371" alt=""><figcaption></figcaption></figure>


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decisionrules.io/doc/space/tests.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
