The Autogenerated Component Test for C

The Component Testing Wizard analyzed the file UmtsCode.c and produced a test script called UmtsCode.ptu. What does this test do?

To edit the generated .ptu script:

  1. In the Project Browser tab on the right-hand side of the screen, open the file UmtsCode.ptu by double-clicking it.

  2. Maximize the test script window that has just opened, closing the lower Output Window to free up some additional space.

  3. Click the Asset Browser tab on the right-hand side of the screen and select the By File sort method.

On the Asset Browser tab you now see each of the five UmtsCode.c functions listed as a child of the test script UmtsCode.ptu. Each requires its own test; all test scripts are stored in the .ptu file. Back on the Project Browser tab, you'll notice that the .ptu file is associated with the source file upon which it was based. The idea is that when you build the UmtsCode component testing node, you are actually building a test harness comprised of the .ptu file, the original source file, the referenced header file and  any stubs required for the simulation of as yet undeveloped code. The build process and test execution, as you recall, is managed by the information stored in a Configuration which, in turn, is based on the information stored in a Target Deployment Port.

Component testing scripts for C and Ada are written with a compiler-independent test script API. For detailed information about the script layout, take advantage of the Test RealTime Reference Guide accessible via the Help menu. For the tutorial, only critical script elements will be pointed out.

  1. In the Asset Brower tab, double-click the node code_int (child node of UmtsCode.ptu).

Of particular note are the Service blocks in a test script. Each function in the file under test is assigned its own Service block. Each Service block can consist of one or more Test blocks. Each Test block consists of data-driven calls to the function under test.

Here you see the Service block for the UmtsCode.c function code_int. This is then followed by native C language calls (indicated by the # symbol) used to declare the variables x and buffer[200] that are passed to the function code_int, the function containing the while statement for which we intend to improve code coverage. As a reminder, here is the declaration for code_int:

void code_int(int x,char *buffer)

The variable declarations are followed by an Environment block. The Environment block is used to define input (called init - i.e. initial) and output (called ev - i.e. expected value) values for the variables passed to the function under test. In the Environment block for the code_int Service block, x is initialized to 0 and has an expected value of init - that is, a value of 0, the initial value. buffer is initialized to nothing - which means each of its 200 array elements are set to 0 - and it has an expected value of init as well.

The Test block for code_int consists of a call to this function. Have you noticed that there is no mention of a return value? Since code_int returns void, nothing is returned - there is no return value to check.

  1. In the Asset Browser tab on the right-hand side of the screen, open the decode_int node and then double-click on the icon for test 1.

Look at the Test block for the function decode_int - in this case, a return value is expected - referred to as  #ret_decode_int. Notice how the Environment block for the decode_int function includes an expected value for #ret_decode_int.

You now understand the essence of HCL OneTest Embeddedcomponent testing test script for C and Ada.

For the purposes of performing useful work, the test script needs to be more detailed than it is immediately following generation. You need to create good tests that supply relevant input values and then verify appropriate output values. Rather than writing it yourself, a revised test has been created for you.