# Unit tests for scripts ## 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 a 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 run after clicking the button **Run all**, * Input parameters - the values we want to test for a given script, * Application data, * Output verification - the values we expect for the input values provided: * 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 in green - the tests ended with the expected result - or in 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 runs. The log drawer contains information about each previous execution, separated by a blank line. The log drawer can be cleared of logs using the button **Clear logs**.

Figure 4. Test with a positive result

Figure 5. Test with a negative result

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

Figure 6. Defining application data in unit tests

Figure 7. Result of running the test with application 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 include the reason and location of the error.

Figure 8. Error after running the test

### Ways to verify 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 | | >= | Greater than or equal to | | < | Less | | <= | Less than or equal to | | == | Numbers are equal | | ≠ | Numbers are not equal | When selecting one of the above comparison operators, keep in mind that the script outputs 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 the following 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.

Figure 9. Test input parameters

Figure 10. Test result verification parameters

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

**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 by the script is not equal to the text value **6** entered in the expected field.

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

#### Script validators The output of script validators is verified 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 the assertion correctly, 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: 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.