> 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). # Script unit tests ## Test scenarios ### Creating a unit test For each script (services and validators), test scenarios can be defined. After clicking the button **Unit tests** in the left sidebar, the test panel will open. The panel displays the currently defined test cases for the given script. A new test can be added using the button at the bottom of the panel **Add test**.

Figure 1. Unit test panel

Each scenario has the following to define: * Test name, * Test description, * Activity - whether it is launched by clicking the button **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: * Output parameters for services, * Message keys for validators.

Figure 2. Test input parameters

Figure 3. Test result verification parameters

### Unit test results The selected test can be run by clicking the icon ![](/files/109c8065abb2df548bf410dfa06ee03a5c03c60e) located on the tile with information about the test scenario. Clicking the button **Run all** 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 run, a log drawer will appear containing information: * The name of the test that was run, * Test logs, * Output value. If all tests are run, the execution time will be the sum of all test executions. In the log drawer there is information about each previous run, separated by a blank line. The log drawer can be cleared using the button **Clear logs**.

Figure 4. Test with a positive result

Figure 5. Test with a negative result

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

Figure 6. Defining request data in unit tests

Figure 7. Result of running the test with request data

### Errors during tests If the script contains errors, the test will fail, and the error will be logged in the console under the editor. The message will contain the reason and location of the error.

Figure 8. Error after running the test

### Ways of verifying output #### Script services The output of script services can be verified in several ways. They are divided into number comparison and text comparison: **Number comparison** | Verification | Description | | ------------ | ------------------------ | | > | Greater than | | >= | Greater than or equal to | | < | Less than | | <= | Less than or equal to | | == | Numbers are equal | | ≠ | Numbers are not equal | When selecting one of the above comparison operators, note that the script output and the values entered for comparison are converted to numbers. If conversion of any value fails, the test will end with a negative result. For example, for data: service output: **6.0**, value to compare: **6**, comparison: **==**, the result is correct. The value **6.0** returned by the script is equal to the value **6** entered in the expected field.

Illustration 9. Test input parameters

Figure 10. Test result verification parameters

Figure 11. Number comparison using the EQ operator with a positive result

**Text comparison** | Verification | Description | | ------------ | ------------------------------ | | EQ | Strings are equal | | NOT\_EQ | Strings are not equal | | \~ | Matches the regular expression | | !∅ | Non-empty | The data are compared as text. Numbers are also treated as text. For example, for data: service output: **6.0**, value to compare: **6**, comparison: **EQ**, the result is incorrect. The text value **6.0** returned by the script is not equal to the text value **6** entered in the expected field.

Figure 12. Number comparison using the EQ operator with a negative result

#### Script validators 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 complete with a successful 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 13. Script validator test with a positive result

Figure 14. Script validator test with a negative result

--- # 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: ``` GET https://docs.eximee.com/documentation/documentation-en/budowanie-aplikacji/logika-biznesowa/scriptcode/testy-jednostkowe-skryptow.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.