> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/scriptcode/testy-jednostkowe-skryptow.md).

# Unit tests for scripts

## Test scenarios <a href="#testyjednostkoweskryptow-scenariuszetestowe" id="testyjednostkoweskryptow-scenariuszetestowe"></a>

### Creating a unit test <a href="#testyjednostkoweskryptow-utworzenietestujednostkowego" id="testyjednostkoweskryptow-utworzenietestujednostkowego"></a>

For each script (services and validators), test scenarios can be defined. After clicking the **Unit tests** button in the left bar, the test panel will open. The panel displays the currently defined test cases for a given script. A new test can be added using the button at the bottom of the panel **Add test**.

<figure><img src="/files/57b096c9b5bd712ee182542ab66d13726bfcb18c" alt=""><figcaption><p><em><strong>Figure 1.</strong> Unit tests panel</em></p></figcaption></figure>

Each scenario has the following to define:

* Test name,
* Test description,
* Activity - whether it is run after clicking the **Run all**,
* Input parameters - the values we want to test for a given script,
* Request data,
* Output verification - the values we expect for the input values provided:
  * Output parameters for services,
  * Message keys for validators.

<figure><img src="/files/c79e7916a21af2b4e39de7150e0073adcf2366d8" alt=""><figcaption><p><em><strong>Figure 2.</strong> Test input parameters</em></p></figcaption></figure>

<figure><img src="/files/1b63b168451801dc461fb2eb0739643952c389ee" alt=""><figcaption><p><em><strong>Figure 3.</strong> Test result verification parameters</em></p></figcaption></figure>

### Unit test results

We can run the selected test by clicking the icon ![](/files/109c8065abb2df548bf410dfa06ee03a5c03c60e) located on the tile with information about the test scenario. Clicking the **Run all** button will run all active tests.

The test result can be marked green - the tests ended with the expected result - or red - incorrect result.

After the test is executed, a drawer with logs will appear, containing information:

* The name of the test that was executed,
* Test logs,
* Output value.

If all tests are run, the execution time will be the sum of all test executions. The log drawer contains information about each previous execution, separated by an empty line. The log drawer can be cleared of logs using the button **Clear logs**.

<figure><img src="/files/72d5e478f48df835bfe61d351daa58578c2c58d0" alt=""><figcaption><p><em><strong>Figure 4.</strong> Test with a positive result</em></p></figcaption></figure>

<figure><img src="/files/c21d9bf2dbd4b236130d18fb3a6ec65c91d58395" alt=""><figcaption><p><em><strong>Figure 5.</strong> Test with a negative result</em></p></figcaption></figure>

### Request data in unit tests <a href="#testyjednostkoweskryptow-danewnioskuwtestachjednostkowych" id="testyjednostkoweskryptow-danewnioskuwtestachjednostkowych"></a>

When creating unit tests, the application allows simulating the data contained in the request. In the **Request data** tab, we can add fields that are to return a specified value. We refer to the provided values using the function *getValue()* available on the *context.*

<figure><img src="/files/a251327a5733b38e61ef58875a538c4580332e6f" alt=""><figcaption><p><em><strong>Figure 6.</strong> Defining request data in unit tests</em></p></figcaption></figure>

<figure><img src="/files/3e6d7c3049537ae705dde98d6519fcc316cc0da9" alt=""><figcaption><p><em><strong>Figure 7.</strong> Result of running the test with request data</em></p></figcaption></figure>

### Errors during tests

If the script contains errors, the test will fail, and the error will be logged in the console below the editor. The message will include the cause and location of the error.

<figure><img src="/files/a1661e5fac497236adafbc72574a950a391a6106" alt=""><figcaption><p><em><strong>Figure 8.</strong> Error after running the test</em></p></figcaption></figure>

### Ways to verify output <a href="#testyjednostkoweskryptow-sposobyweryfikacjiwyjscia" id="testyjednostkoweskryptow-sposobyweryfikacjiwyjscia"></a>

#### Script services <a href="#testyjednostkoweskryptow-sposobyweryfikacjiwyjscia" id="testyjednostkoweskryptow-sposobyweryfikacjiwyjscia"></a>

We can verify the output of script services in several ways. They are divided into number comparison and text comparison:

**Number comparison**

| Verification | Description              |
| ------------ | ------------------------ |
| >            | Greater                  |
| >=           | Greater than or equal to |
| <            | Less                     |
| <=           | Less than or equal to    |
| ==           | Numbers are equal        |
| ≠            | Numbers are not equal    |

When choosing one of the comparison operators above, keep in mind that the script outputs and the values entered for comparison are converted to numbers. If conversion of either value fails, the test will end with a negative result.

For example, for the following data: service output: **6.0**, value to compare: **6**, comparison: **==**, the result is correct. The value **6.0** returned from the script is equal to the value **6** entered in the expected field.

<figure><img src="/files/d61865ca3e56c9b117e5e34e7e0976deeb58e9fe" alt=""><figcaption><p><em><strong>Illustration 9.</strong> Test input parameters</em></p></figcaption></figure>

<figure><img src="/files/25696e6e6b89bb17e090632452d4bd4404ae9f62" alt=""><figcaption><p><em><strong>Figure 10.</strong> Test result verification parameters</em></p></figcaption></figure>

<figure><img src="/files/33d59611a9b926286eb56acdb1be355e94d744b9" alt=""><figcaption><p><em><strong>Figure 11.</strong> Number comparison using the EQ operator ended with a positive result</em></p></figcaption></figure>

**Text comparison**

| Verification | Description                |
| ------------ | -------------------------- |
| EQ           | Strings are equal          |
| NOT\_EQ      | Strings are not equal      |
| \~           | Matches regular expression |
| !∅           | Non-empty                  |

The data is compared as text. Numbers are also treated as text.

For example, for the following data: service output: **6.0**, value to compare: **6**, comparison: **EQ**, the result is incorrect. The text value **6.0** returned from the script is not equal to the text value **6** entered in the expected field.

<figure><img src="/files/d1d0b91983b8966348122f0b95e9234d3daeb75b" alt=""><figcaption><p><em><strong>Figure 12.</strong> Number comparison using the EQ operator ended with a negative result</em></p></figcaption></figure>

#### Script validators <a href="#testyjednostkoweskryptow-walidatoryskryptowe" id="testyjednostkoweskryptow-walidatoryskryptowe"></a>

We verify the output of script validators by selecting the message keys that will be returned in a given test case.

For example, a script validator returns two error keys with their parameters:

* pl.error1
* pl.error2

For the test to end with a correct assertion, both error keys should be on the list.

If we add extra keys or one of the error keys is missing, the test will fail.

<figure><img src="/files/77192fb6ae5951b80721144a09e553ba562a5a2e" alt=""><figcaption><p><em><strong>Figure 13.</strong> Script validator test with a positive result</em></p></figcaption></figure>

<figure><img src="/files/9213285a8cb82405c2289991e7435dfb6eb176b3" alt=""><figcaption><p><em><strong>Figure 14.</strong> Script validator test with a negative result</em></p></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 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.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/scriptcode/testy-jednostkowe-skryptow.md?ask=<question>&goal=<endgoal>
```

`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.
