Elements of a Test Case

Test programs can contain one or more test cases, and each test case can have a number of elements to it. These elements are coded as specific entry points that the Micro Focus Unit Testing Framework can recognize.

The Micro Focus Unit Testing Framework uses a number of call prototypes to help construct the entry point names. These prototypes are located in the mfunit.cpy copybook, which is available from the cpylib directory of your product installation directory.

Note: If you are unable to use the copybook, due to its use of level-78 items, which are not supported with mainframe dialects, you must specify the following entry point names:
Element Entry point
test setup MFUS_test_case_name
test setup (data-driven tests) MFUDS_test_case_name
test metadata setup MFUM_test_case_name
test case MFUT_test_case_name
test teardown MFUE_test_case_name
test teardown (data-driven tests) MFUDE_test_case_name

The main elements are:

The test setup
Any pre-requisite conditions that need to be satisfied before the test case is run can be set up in this section. For example, if the test case requires that a data file already exists or is open ready for input, you can code such things in this section. This section is optional.
...
entry MFU-TC-SETUP-PREFIX & "MyTestCase"
*>initial setup code goes here
goback
...
Tip: Use the snippet testup to enter the stub code for a test setup.
The test setup for data-driven tests
This section performs a similar function to the test setup (above), except that for data-driven, it will only run once, before the first time that the test case is run. Using a normal test setup section would result in the setup being run each time that the test case is executed, and due to the nature of data-driven tests, that would be for each selected row in the data file, which could be inefficient.
This type of setup could be used to include connection details, that ideally only need to run once per test run. This section is optional.
...
entry MFU-TC-SETUP-DD-PREFIX & "MyTestCase"
//initial data-driven setup code goes here//
goback
...
The test metadata setup
There are a number of metadata details that you add directly through your source code, such as test description and test timeout; see Using Dynamic Metadata. For data-driven tests, this section must at least contain the MFU-MD-TESTDATA metadata declaration; for all other test types, this section is optional.
...
entry MFU-TC-METADATA-SETUP-PREFIX & "MyTestCase"
*>initial metadata setup code goes here
*>e.g. move "csv:mycsvfile.csv" to MFU-MD-TESTDATA
goback
...
Tip: Use the snippet testdata to enter the stub code for adding test metadata.
The test case
This section contains the actual testing logic and test assertions.
...
entry MFU-TC-PREFIX & "MyTestCase"
*>test case code goes here
goback
...
Tip: Use the snippet testcase to enter the stub code for a test case.
The test teardown
This section enables you to tidy up the environment, such as releasing or closing resources, after the test has been run. This may be critical if you run multiple test cases within a test suite. This section is optional.
...
entry MFU-TC-TEARDOWN-PREFIX & "MyTestCase"
*>clean-up code goes here
goback
...
Tip: Use the snippet testdown to enter the stub code for a test teardown.
The test teardown for data-driven tests
This section performs a similar function to the test teardown (above), except that for data-driven, it will only run once, after the last time that the test case is run. Using a normal test teardown section would result in the test environment being torn down after test case was executed, and due to the nature of data-driven tests, that would be for each selected row in the data file.
This type of teardown could be used to include disconnection details, that ideally only need to run once per test run. This section is optional.
...
entry MFU-TC-TEARDOWN-DD-PREFIX & "MyTestCase"
//clean-up code goes here//
goback
...

Test cases cannot share setups or teardowns; you must code a separate setup or teardown for each test case that requires one.

The sections relating to a test case can appear in your code in any order, but are run in the order shown here.