Function: The dialog inserts a new test POU for the IEC unit test.
Call:
Project menu, Add Object command
Context menu of the Application object, Add Object command
Table 84. Implementation
Name of POU | The name of the test case POU to be generated. Later, the test case execution can be conditionally controlled based on the names of test cases. In addition, the name is displayed in the test report. |
Type | Extend TM.Testcase (recommended) This template provides an easy-to-use scheme for a single test case. It consists of a series of methods and outputs to perform test-specific tasks. When the test is executed, the methods of the POU are called in the following order: Setup() (optional, one-time call) provides the capability to prepare the testee and test.
Execute() (required, called in the loop) is used to stimulate the testee and check its results. The method is called until it returns TRUE. To report failure or success, Assert Functions is used. The Info VAR_OUTPUT of the POU can also be used to add textual details to the test report, but they could be mutually overwritten by assert functions.
Teardown() (optional, one-time call) provides the capability to clean up and reset the test after it has finished.
Abort(): If the test POU is aborted by setting the VAR_INPUT xAbort to TRUE, then this method is called repeatedly until it returns TRUE. This provides the capability to clean up a running test even if it is aborted. The IEC Unit Test test element aborts a test POU, for example, when the timeout for the test case has elapsed.
Extend TM.BaseMultiTest
This scheme is suitable for the implementation of a series of test cases. The interface of the scheme (see TM.BaseMultiTest) is called multiple times in different contextual phases for each individual test case. The template assigns the following tasks to the IFBCommand methods of CBM.ETrigA: prvStart() (optional, one-time call) provides the capability to prepare the testees and test.
prvCyclicAction() (required, called in the loop) is the location to stimulate the testee and check its results. This method is called multiple times in different contextual phases for each individual test case:
Before the actual test execution (input xGetTestInfo := FALSE), information is collected about the individual test cases of the POU. In this phase, the input xGetTestInfo has the value TRUE. With the value -1 at the diTestCaseIndex input, the number of test cases is queried at the diTestCaseCount output. Then there is a sequence of queries which varies the values of the diTestCaseIndex input from 0 to n-1 in order to query the TestCaseName, TestCaseCategories, and diTestCaseTimeout information for each test case. Each query is performed by the Test Manager in a closed cycle of xExecute := TRUE, waiting for xDone = TRUE. or xError = TRUE and resetting the xExecute input to FALSE. Therefore, the test is executed as a sequence of closed cycles (xExecute to xDone or xError) which varies the diTestCaseIndex input from 0 to n-1. In doing so, the xGetTestInfo input is always left at the value FALSE. To report failure or success, Assert Functions is used here. The Info VAR_OUTPUT of the POU can also be used to add textual details to the test report, but they could be mutually overwritten by assert functions.
prvAbort() is called repeatedly when the xAbort input of the POU is TRUE and until the xAbortInProgress VAR of the POU is set to FALSE. This provides the capability to clean up a running test in every state.
|
Add optional methods | According to the type, adds the standard methods, which are marked as optional above, for setting up, canceling, and resetting the function block. |
Add implementation template | Fills all generated methods with a sample implementation of a test case which uses "TODO" comments to make it clear where custom test logic should be used. This option is recommended when a test case is completely rewritten. |
Add explanatory comments | Inserts a code comment, which explains the basic operation of the POU pattern, in the declaration part of the test case function block and each of its methods. This option is recommended if the pattern is not yet known. |
Table 85. Optional Attributes
Test Case Name | A name for the test case, which is then used instead of the name of the POU. For more information, see: Pragmas in Test POUs |
Test Case Category | A comma-separated list of categories which the test case belongs to. Later, the test case execution can be conditionally controlled based on the categories of test cases. For more information, see: Pragmas in Test POUs |
Test Case Timeout | The time which the test case may take to execute. If the test case takes longer, then it is aborted and the abort method is called if necessary. With value 0, the timeout can be set to infinite. |
Test Case Group | Adds the testcasegroup attribute in the declaration part |
Test Case Group Timeout | Adds the testcasegrouptimeout attribute in the declaration part |