Working storage in the unit test

[Munken]

When mocking a section that fetches data row by row, then local variables would be handy.

When preprocessing then this Working storage section should be placed into a copy book
and injected together with CCHECKWS.CPY.

Example:

WORKING-STORAGE SECTION.
03 WS-UT-IDX               PIC  9(03).

TESTSUITE 'TEST SUITE NAME'

TESTCASE 'TEST CASE #1'                     
  MOCK FETCH-DATA
    IF WS-UT-IDX = 0
      SET WS-STATUS-OK TO TRUE
    ELSE
      SET WS-FAIL-OK TO TRUE
    END-IF  
  END-MOCK                                                       

[neopragma]

This is an interesting idea, but I have a question about it. In the sample code you provide, there is branching logic within the unit test case. It is generally-accepted good practice that unit test cases have no branching logic. The preferred way to express the behavior represented here would be to have the mock set WS-STATUS-OK in one test case, and set WS-FAIL-OK in a separate test case. If we structured this as two separate cases, there would be no need for the additional Working-Storage item. I suggest we keep this item in the issues list in case further discussion leads us to implement it.

[Munken]

A better example would be mocking a row by row sql cursor fetch. I don't see how you could easily split this into multiple test cases?

'''
WORKING-STORAGE SECTION.
03 WS-UT-IDX PIC 9(03).

TESTSUITE 'TEST SUITE NAME'

TESTCASE 'TEST CASE #1'
MOCK FETCH-DATA
IF WS-UT-IDX < 5
SET WS-STATUS-OK TO TRUE
ELSE
SET WS-FAIL-OK TO TRUE
END-IF
ADD 1 TO WS-UT-IDX
END-MOCK
'''

[neopragma]

Interesting. It reminds me of functionality in mockito whereby we can have a mock return a series of different values as the mock is called multiple times. This could be a useful idea to adapt to Cobol Check. I'm going to mark it for an upcoming release so we won't forget about the idea. Thanks!