Restrictions when using the test frameworks
This article contains the restrictions that you should know and observe when you are using the test framework.
When creating/executing a test suite
The following restriction is valid, when you create and execute test suites.
It is possible to test the following →POUs:
Restriction: It is not possible to test a →method or an →interface. Moreover, Neuron advises against creating tests for the elements of →object-oriented programming (even if this would be possible). Reason: It cannot be guaranteed that the tests for these elements will be correctly created and processed. The best practice is to assign a name to a POU that is shorter than 30 characters. If the POU has a longer name, the required test case is automatically shortened when the test suite is created (i.e. when it is exported to Excel). |
It is not possible to create or execute a test suite for a POU with →references. |
If a test suite is created for a →program with internal →variables ( |
If a test suite is created for a →program with →input variables and/or →output variables. these variables are ignored. That means that there are no appropriate columns within the test case. |
If a test suite contains special characters (such as umlauts, e.g. ä, ö, ü), these special characters are ignored when the test is running. Hence, best practice is to use only ASCII characters when creating/modifying the test suite. |
If the test is repeatedly executed, the files for the test execution are overwritten. |
It is possible that the information on the test coverage is not correctly generated for certain scenarios within the ST-editor. See "Restrictions on representing the test coverage within the ST-editor". |
When modifying a test suite
The following restrictions/recommendations are valid, when you modify test suites.
Create only up to 5.000 test sequences per Excel file. This limitation is valid as sum all test cases. |
Enter up to 55.000 data per test case. Mind that the data is calculated as follows:
If you enter more data within a test case, the following message appears when the test case is executed: Workaround, if there are unspecified test sequences within the test case: Uncheck the setting Validate results for unspecified test sequences before you start the test. |
Valid values for input data or for expected results Valid values are →literals with the following exceptions: →Character string literals are not supported. Examples: |
Behavior for external variables It is not possible to test →external variables within a function. The usage of an external variable within the program or the function block under test (= POU) determines how this external variable is specified within the test case: A column for an input exists, if the external variable is only read within the POU. A column for an output exists, if the external variable is only written to within the POU. This is also the case, if the external variable is read as well within the POU. |
Behavior for structure and array elements Only one column exists per input or output that is based on a →structured data type or →array data type. You have to enhance the column name to address one element. See "Accessing the structured data type and structure elements" and "Accessing the ARRAY data type and ARRAY elements", if you need information on the appropriate syntax. |
If you are using Excel formulas in order to calculate the expected results for REAL
or LREAL
values (e.g. the formula to calculate a sine value), round these results to the significant digits within the Excel file (e.g. use the formula to round the value). Reason: Neuron Power Engineer calculates the REAL
and LREAL
values with the appropriately significant digits (details: see information on the REAL
and LREAL
data type).