The C++ component test report summarizes all of the test results. It is hyperlinked to the test script (the .otd and .otc file) and can be browsed using the Report Window.
To analyze the test report:
In the Project Browser tab on the right-hand side of the screen, right-click the PhoneNumber component testing node and select View Report->Code Coverage.
Maximize the Code Coverage viewer
Using the Report tab on the left hand side of the screen, view the source code for the PhoneNumber constructor you called with a value of 0 in your test script.
Have you covered the 0 loop case of the for loop? Yes, indeed. (Notice the absence of coverage for 2 loops or more - remember, in your component test, only the 0 case was tested. Your manual interaction with the UMTS base station via the mobile phone simulator was responsible for the 2 loops or more coverage - and that coverage won't be listed here.)
How about your contract checks?
In the Project Browser tab on the right-hand side of the screen, right-click the PhoneNumber test node and select View Report->Test.
Close the Project Explorer window to the right, and the Output Window at the bottom of the UI to give you more room to explore the report.
Look at the Report Window on the lower-left side of the UI. Your method contract check failed - that is, the stringLength variable was not greater than 0. It should come as not surprise that this assertion failed since you went out of your way to supply a length of 0. Sensibly, you should continue to test this assertion in all your regression testing of the UMTS server to ensure that "normal" phone number inputs never have a length of 0.
Does anything else need to be done? Is everything else working properly?
Notice how the test cases corresponding to the methods appear to have failed as well. Why should this be? As you recall, no test was actually performed in the Test Case block - you simply called the PhoneNumber() constructor. In fact, this failure implies the test was not able to finish properly. You should take a closer look at the runtime trace to ensure nothing unusual happened.
Select the Runtime Trace tab.
Look closely. There are lifelines for:
the operating system
the test class block
the test case that calls the PhoneNumber constructor
a PhoneNumber object
Your assertion checks are flagged by notes - a green note means the assertion has been observed, a red note means the assertion has been violated. (Thus the note for the stringLength test is red.)
What about the unexpected exception? That can't be good. In fact, close inspection of the PhoneNumber lifeline shows that the destructor method was never called. Intuition probably tells you that this unhandled exception is directly related to your input of a phone number of 0 length.
The code needs to be fixed.