0 Bewertungen0% fanden dieses Dokument nützlich (0 Abstimmungen)
82 Ansichten28 Seiten
This document provides an overview of zUnit, a framework for automated unit testing on z/OS. It discusses configuring the zUnit test runner, creating test cases, running and viewing test results. Key aspects covered include adding tests to a test case, using setup and teardown routines, and invoking assertions to fail tests and record failure messages. The document also demonstrates moving the test runner configuration to a z/OS system and invoking the test runner via JCL.
This document provides an overview of zUnit, a framework for automated unit testing on z/OS. It discusses configuring the zUnit test runner, creating test cases, running and viewing test results. Key aspects covered include adding tests to a test case, using setup and teardown routines, and invoking assertions to fail tests and record failure messages. The document also demonstrates moving the test runner configuration to a z/OS system and invoking the test runner via JCL.
This document provides an overview of zUnit, a framework for automated unit testing on z/OS. It discusses configuring the zUnit test runner, creating test cases, running and viewing test results. Key aspects covered include adding tests to a test case, using setup and teardown routines, and invoking assertions to fail tests and record failure messages. The document also demonstrates moving the test runner configuration to a z/OS system and invoking the test runner via JCL.
Agenda Introduction to zUnit Configuring the test runner Creating a test case Running a test case Viewing test case results Interpreting test case results
Chris, this Presentation is not laid out as per the above mentioned format. You might want to make use of the above headings if going as per IBMs infocenter or change as required.
zUnit xUnit umbrella for all testing unit e.g. JUnit, zUnit, etc zUnit is a framework targeted towards code based development of test cases and specifically for unit testing. Test cases would verify code behaves as expected. zUnit does not provide comprehensive tooling for connecting to databases or mocking of transactional systems. In unit testing you have Modules you want to test, for which zUnit allows you to create test cases which can have n no. of individual tests, run by the Test Runner. Each test case could do any no. of individual test against a module. Test runner loads test case and begins calling the individual test inside the test case. z/OS Automated Unit Testing Framework Configuration RESULTS TEST RUNNER
AZUTSTRN AZUTCINI() AZUTCADD() AZUASTFA() AZUASTFM(msg) Test Case 01 Test Case 02 Test Case 03 Test Case nn addTests() Setup() Teardown() (test1,,testn)() PDS(E) Test Runner API zUnit Each test in the end could indicate to the test runner if test failed. If any of the individual test case fails the entire Test Case would be considered as failed. Status of test is communicated, for e.g. within Anagram2 supplied strings which are ANAGRAM to each other. If results says not than we can call an API to make an assertion. Assertion causes information to be brought back to the test runner stating -- "I was in the test and it failed and this is the reason". User can provide a string indicating why the test failed, the test runner can than move to the next test in the test case and whichever test had failed and the causes of the failure and including trackback information will be in the report.
Test Runner Test Case Assertions Test Fixture Test Execution Test Runner API Chris, you might want to add brief description for the above. You can find info on them at : http://pic.dhe.ibm.com/infocenter/ratdevz/v8r5/index.jsp?topic=%2Fcom .ibm.etools.rdz.zunit.doc%2Ftopics%2Ft_run_test_case_tso.html TEST CASE INVOKING THE TEST RUNNER TESTCASE () ADDTESTS () TESTnn () SETUP () TEARDOWN TEST01 () ZUNIT.COBOL.SOURCE AZUTCINI() AZUTCADD() AZUASTFM() AZUASTFA() zUnit Test Runner API Invoking Assertion APIs in the SETUP, TEARDOWN or active TEST entry fails the current test. EXPLAINING TESTMEMBER VIA OUTLINE VIEW
PROGRAM:TESTCASE Testcase is first going to be loaded and initialized by the test runner PROGRAM:ADDTESTS The test runner is going to give the test case opportunity to add unbounded no. of tests. Tests are going to be dynamically added by the test case itself and do not have to be predetermined though the wizard makes it seem like that. Individual tests can have descriptive names. PROGRAM:SETUP Before each individual test is run an environment suitable to the test is established. I you need to allocate required data structures, any mockup, objects in order to run any of the tests (TEST001 to TESTnnn) you would do it in the SETUP. PROGRAM:ANAGRAM1 Once setup is done - the test runner would call the ANAGRAM1 sub-program and this is a test(ANAGRAM 1) - this entry point is passed for information and its in here that the Programmers write the code that its going to call the program they want to test passing along the data structure that was allocated in the setup program. PROGRAM:TEARDOWN
Creating a local project (zUnit2) Adding folder to local project (src) Creating test runner config (zUnit2 srcAZUCF002) Moving test runner to z/OS (remote system) To move the test runner configuration AZUFC002 to your z/OS (remote system) first allocate dataset <HLQ>.ZUNIT.AZUCFG Record format : VBA Record Length : 16381 Data set type : LIBRARY
Note : same characteristics are for dataset where the results will be generated <HLQ>.ZUNIT.AZURES Moving test runner to z/OS (remote system) Make sure the transfer of test runner configuration from local project to remote system happens in binary mode. After copying the test runner configuration over to the remote system, double click to see its settings and select as required. The test runner by default assumes that a test case of its same name exists. You can remove the test case AZUCF002 and add the test case (load module) you created since a test case has not been loaded. After the test case has been created and submitted, you can add the load module to the test runner to resolve the above error. Creating a test case Add test case to test runner Select runner configuration settings as desired, save and close the test runner. INVOKING THE TEST RUNNER Test runner can be invoked via TSO Ready Prompt Unix System Services (USS) and Job Control Language (JCL)