It is possible to test the following →POUs:

1. user-defined POUs that are located in the current project (e.g. within a →folder of the project) and their name does not start with the character _

2. POUs located within →libraries and their name does not start with the character _
   The POUs might be user-defined POUs or system blocks.

3. POUs not using one of the following blocks within the POU under test because they are not supported when a test is executed:
   

   • Page:GET_EP_TICKS block

   • Page:SET_EP_TICKS block

   • Page:SysTaskActualCycleTime block

   • Page:SysTaskCycleTime block

   
   If you do use one of these blocks within the POU under test anyway, it is not guaranteed that the test is correctly executed. The respective block article contains information about why the block is not supported when a test is executed.

Restriction: It is not possible to test a →method or an →interface . Moreover, logi.cals 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. In logi.CAD 3, it is possible to declare the following elements of the object-oriented programming:

• →interfaces

• →methods

• →function blocks that are derived from a base function block (by using the keyword EXTENDS)

• function blocks that are implementing i nterfaces (by using the keyword IMPLEMENTS) and/or that are containing methods

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 ( VAR ... END_VAR ) . these variables are ignored. That means that there are no appropriate columns within the test case.

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.
Workaround 1: If you want to keep the files for a test execution, move the files to a different folder and/or rename them so that they have unique names. Example: The test report report.html becomes report_180329_1.html.
Workaround 2: If you want to have an overall test report for several test suites, select these test suites within the same project and select the appropriate command for the test execution. Result: The tests are executed for all selected test suites. Subsequently, the test report report.html contains the information on the test execution of these test suites.

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

Create only up to 5.000 test sequences per Excel file. This limitation is valid as sum all test cases.
In case of more test sequences, the optimal usage of the test framework cannot be guaranteed but the test execution might behave sluggishly.

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: Test case contains too many test sequences and/or inputs/outputs

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 are →literals with the following exceptions: →Character string literals are not supported. Examples: 'OK' or 'B'Hence, variables of the data type STRING or CHAR cannot be checked by using the test framework.

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.

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.
Moveover, you must insert an additonal column per structure or array element that should be specified within the test case. For all other elements, specify the defaults within the worksheet Defaults.
Please mind that the test framework does not check whether the test case includes each element for such input variables.