rhapsody in c++ tutorial - ibmtutorial for ibm ® rational® rhapsody® testconductor add on 2...

Tutorial for TestConductor for Rhapsody in C++

Rhapsody in C++ Tutorial

for

IBM® Rational® Rhapsody® TestConductor Add On

2

License Agreement No part of this publication may be reproduced, transmitted, stored in a retrieval system, nor translated into any human or computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual or otherwise, without the prior written permission of the copyright owner, BTC Embedded Systems AG.

The information in this publication is subject to change without notice, and BTC Embedded Systems AG assumes no responsibility for any errors which may appear herein. No warranties, either expressed or implied, are made regarding Rhapsody software including documentation and its fitness for any particular purpose. Trademarks

IBM® Rational® Rhapsody®, IBM® Rational® Rhapsody®

Automatic Test Generation Add On, and IBM® Rational®

Rhapsody® TestConductor Add On are registered trademarks of IBM Corporation. All other product or company names mentioned herein may be trademarks or registered trademarks of their respective owners. © Copyright 2000-2019 BTC Embedded Systems AG. All rights reserved.

3

TestConductor is the test execution and verification engine in the Rhapsody Testing Environment. Requirements and specifications are captured by sequence diagrams, flow charts, statecharts, and using source code. During execution TestConductor verifies the test application generated from the model against these test specifications.

TestConductor offers different measures for test quality, adapted tothe testing activities in different phases of the development process:• Model Element Coverage• Requirement Coverage• Code Coverage.

In this tutorial we would like to give you an impression of the Rhapsody Testing Environment, which goes beyond current embedded software testing technologies; it ensures that the system can be continuously tested throughout the design process. The Testing Environment and its parts seamlessly integrate in Rhapsody UML and guide the user through the complex process of test preparation, execution and result analysis.

By integrating model based testing with model based development, the Testing Environmentsupports the model based development with various test techniques and full traceability among testing and modeling artefacts.

TestConductor for Rhapsody in C++

4WindowControl Model

The WindowControl application, the exampleC++ application for this tutorial, models a simple 'smart home' application. Make yourself familiar with the use cases of the application. Open the project „CppWindowControl” from the folder „Samples/CppSamples/TestConductor“ in your Rhapsody installation, ● run the component „Model::execscope::Simulation” by invoking

Generate/Make/Run, ● press 'Go' button in the appearing animation toolbar, and● use the automatically opening panel:

1 Set the target room temperature by turning the left knob to 20 degrees.

2 Set the room temperature by turning the second left knob to 25 degrees. window opens to ventilate.

3 Set the outdoor temperature by turning the knob in the middle to 30 degrees. window closes to end ventilation.

4 Set the outdoor temperature to 15 degrees. window opens again.

5 Set the windspeed to 55 km/h by turning the windspeed knob. window closes to end ventilation.

5WindowControl Model

The WindowControl model is a 'smart home' application which controls opening and closing a window for ventilation. The house owner determines the desired room temperature. Class roomclimate calculates the need for ventilation from the actual room temperature, the desired room temperature as well as from the actual outdoor temperature. Class windowcontrol reacts on events from roomclimate by opening and closing the window, taking into account whether storm or rain enforce closing the window.Classes raindetection and stormdetection evaluate sensor data with thresholds and indicate begin and end of rain and storm periods, respectively.

Actors User and Sensor provide the model classes with desired target room temperature and sensor data room temperature , outdoor temperature, wind speed and actual rain.

Actor Actuator takes over the role of mechanically opening and closing the window.

6System Under Test

● Defining the System Under Test (SUT) is the first step in the test workflow. To define windowcontrol to be the SUT, we have to create a test architecture.

● Backbone of a test architecture is the so-called TestContext, defining the structure of the test system.

● TestComponents form the test environment of the SUT accor-ding to its relations to other model elements.

● The SUT and the TestComponents are instantiated as parts of the TestContext and are connected appropriately.

● TestComponents will be instrumented for testing purposes.

● The needed administrative framework or “test harness” will be placed in the folder TestPackages.

1

Select the class „windowcontrol” in the browser and choose from context menu „Create TestArchitecture“.

Have a look on the newly created Test Context Diagram „Structure_of_TCon_windowcontrol“, and view the resulting parts and their connections in the composite class „TCon_windowcontrol“ of our TestContext.

2

7Test Architecture

The new configuration under the component „TPkg_windowcontrol_Comp“ defines the code generation and build settings to generate an executable test application, as well as settings for the actual test execution.

A TestContext describes the context in which TestCases are executed. It is responsible for defining the structure of the test system.The TestContext will also be the owner of the TestCases.

A TestComponent is a class of the test system. TestComponentInstances realize partially the behavior of a test case. TestComponents will be instrumented with observation functionality, driver operations and stubs for testing purposes.

The automatically created test architecture is completely represented in the browser and seamlessly integrates into Rhapsody; think of it as an independent test model besides the design model. After creation the following elements are visible:

8Test Context

The composite class „TCon_windowcontrol“ is the part container for the SUT object and the created TestComponent objects.

The automatically created TestContext represents the formal structure of the test system. TestConductor analyzed the model structure in consideration of the selected SUT and proposed a test structure, which is visualized in the TestContextDiagram inside the TestContext. TestConductor generated corresponding TestComponents for ports and associations of the SUT.

TC_at_inputs_of_windowcontrol is a TestComponent connected to port inputs of the SUT. The TestComponent can act as an abstraction of roomclimate.

TC_at_storminfo_of_windowcontrol can act as an abstraction of stormdetection.

TC_at_raininfo_of_windowcontrol can act as an abstract representation of raindetection.

TC_at_act_of_windowcontrol is a TestComponent at port act and can serve as an abstraction of actor Actuator.

9Test Cases

is a specification of one case to test the system including what to test, with which inputs, and what the expected outcomes are. It is defined in terms of stimuli injected to SUT objects and observations coming from SUT objects.

specifies how cooperating TestComponents interact with the SUT.

is an operation of a TestContext. A TestCase is a regular model element of the test system. Usual modelling techniques, such as adding relations for traceability, can be applied to TestCases.

can be specified as sequence diagrams, using an operation flow chart, using a TestComponent with a statechart, or simply using source code in a TestCase operation body.

can be generated from an existing sequence diagram and, hence, can be generated from an animation record or from an existing specification.

defines an automated test procedure which is defined once, can be maintained with respect to model changes and can be applied on demand.

TestCases are the purpose and meaning of a test system. A test architecture around the SUT has been created with a few mouse clicks in less than a minute. The test architecture provides the executable environment in which the SUT can be stimulated and observed by individual TestCases. A TestCase ...

10Test Case Specification

Flowchart TestCases also benefit from their graphical nature, but in contrast to sequence diagrams focus on the control flow of the test procedure instead of focusing on the communication. Flowchart TestCases lack easy-to-use mechanisms for specifying timing. They have their strength in systematically testing individual operations.

How to manually create TestCases and how to execute them with TestConductor will be discussed in the following sections. The different kinds of definitions have their own strengths:

Sequence diagram TestCases have their strength in specifying and testing protocol and communication scenarios. Series of actions and reactions of the SUT can be specified in a simple and concise manner. Also timing aspects of actions and reactions can specified and tested easily. The graphical formalism allows for abstracting from testing details. Intuitive graphical formalisms enable easy readability and improve comprehensibility.

Source code TestCases are often preferred by experienced programmers. Having the same expressiveness as Flowchart TestCases, code TestCases are the easiest, but least intuitively readable method to specify test procedures.

Statechart TestCases do not play an important role in practise and will not be exercised in this tutorial. Although a statechart can be used to stimulate the SUT, the SUT will - without modifications - in general not send 'answers' to the stimuli. Hence, statechart TestCases lack advanced methods to observe reactions of the SUT. Except for beeing able to wait for timers, statechart TestCases do not go ahead expressiveness of flow chart and code TestCases.

11Test Case: Sequence Diagram I

To manually create a sequence diagramtest case we have to define a test scenario which is represented as a sequence diagramand link it to a test case. TestConductor simplifies this process with a single command.

1 2 3Select the test context „TCon_windowcontrol“ in the Rhapsody-Browser ...

... and choose from the context menu „Create SD TestCase“..

Rename the test case to „SD_tc_sunny_day“. Rename the test scenario to „sunny_day“ and open it.

12Test Case: Sequence Diagram II

Determine the involved objects for the desired test scenario and remove not needed instance lines from the view in order to establish action and reaction between remaining instances.

1 2

Select the instance line „itsTC_at_rainevs_of_windowcontrol” and press the delete button.Do not use 'Delete from Model', since this also deletes the TestComponentInstance itself.

Arrange the remaining instance lines, such that communication flows from left to right.

13Test Case: Sequence Diagram III

Define action and reaction of the system under test. We will specify the „sunny_day“ scenario, in which windowcontrol is stimulated with evVentilation via its in port inputs and will react by invoking cmd_openwindow() on its out port act. TestConductor, the execution engine, shall act as driver for evVentilation, and as observer for cmd_openwindow(). Driving means to force the respective TestComponent during test execution to send the message to the SUT in order to stimulate a reaction. The TestCase will pass, if TestConductor observes the specified reaction of the SUT. Otherwise it will fail.

1 2

Draw the driving message „evVentilation()“ from „itsTC_at_inputs_of_windowcontrol“ to „itsWindowcontrol“:You can simply draw a message and enter its name or you can select an interface item from the context menu on the message (select message) or select an interface item in the features dialog (Realization).

Draw the message „cmd_openwindow()“ from the SUT „itsWindowcontrol“ to „itsTC_at_act_of_windowcontrol“ such that it can be observed (for this TestCase, it makes no difference whether cmd_openwindow() or actitf::cmd_openwindow() is chosen).

14Test Case Execution

Status of execution: „NOT EXECUTED”, „EXECUTING”, „ERROR”, „PASSED“ or „FAILED“.The progress displays how many steps are finished yet. In case of a passed sequence diagram TestCase 100% have to be achieved.The buttons in the top right corner of the execution dialog can be used to control actual TestCase execution and will be explained later.

Execute the TestCase with Rhapsody TestConductor.The execution dialog lists all executed TestCases, their progress and status.

1 2

To execute the test case with TestConductor select the test case „SD_tc_sunny_day“ and choose from the context menu the items „Update TestCase“, „Build TestCase“, and „Execute TestCase“. The Rhapsody TestConductor execution dialog will open.

The TestCase execution dialog is a dockable dialog that can be placed e.g. underneath the main browser window.

15Test Case Modification and Re-Execution

We now modify and re-execute the TestCase.

2 2

To re-execute the modified TestCase select the TestCase „SD_tc_sunny_day“ and „Execute TestCase“.

Execution of the modified TestCase passes.3

TestConductor notices the modifications and prompts for „Update, Build and Execute“ confirmation.

4

1

Extend the TestScenario „sunny_day” of TestCase „SD_tc_sunny_day” with two further messages

16Copying Test Case, Modification and Execution

We now copy a TestCase, modify and execute the copied TestCase. It is strictly recommended to do a „Clean TestPackage“ before copying a TestCase. „Clean TestPackage“ removes the temporary test artefacts, such as driver operations and observation instrumentation, created by „Update TestCase/TestContext/TestPackage“.

1

2

Invoke „Clean TestPackage“ on TPkg_windowcontrol.

4

Rename the created copy SD_tc_sunny_day_copy toSD_tc_storm. Rename TestScenario of SD_tc_storm to storm and open the TestScenario.

5

Modify TestScenario storm, s.t. itsTC_at_storminfo_of_windowcontrol sends evStorm between itsWindowcontrol's reaction on evVentilation and reception of evNoVentilation.

2 Copy TestCase SD_tc_sunny_day. 3 Paste on TestContext

TCon_windowcontrol.

17Witness Scenario

1 2 3

To create and open the witness scenario right click the item SD_tc_0 in the TestConductor execution dialog…

... and select “Show as SD”.The witness scenario is added to the model for later inspection.

In the browser, below the TestCase, you can find the generated witness scenario also for later use.

The TestCase execution FAILED with Rhapsody TestConductor. To analyze the reason TestConductor offers a witness scenario to display the error or the reason for failure, respectively. Colors are used to visualize the difference between observed and specified behavior. Messages are colored green if they were observed as specified. Blue messages are either not observed or are not observable at all.

Red messages denote the observation which led to the failure. In addition to coloring the message red, TestConductor also annotates the message with a short characterization of the mismatch between specification and observation.

18Witness Scenario II

1 2 3

... and re-execute TestCase by pressing the play-button of the execution window.TestConductor will prompt for Update and Build confirmation.

Test execution for modified SD_tc_storm passed. 'Show as SD' now shows all 6 messages colored green.

The Witness Scenario shows that evVentilation was driven and windowcontrol invoked cmd_openwindow() on its out port act in accordance with the TestScenario. Then windowcontrol was stimulated with evStorm and before the next specified event evNoVentilation was sent to windowcontrol, windowcontrol unexpectedly reacted on event evStorm by invoking cmd_closewindow() on its out port act.

Note that not all messages appearing in an execution have to be specified in the TestScenario. But if a particular message (like cmd_closewindow) is specified once, then all its occurrences have to be specified. Otherwise unspecified occurrences of the message are considered unexpected.Inspection of the statechart of windowcontrol reveals that windowcontrol reacts on evStorm by invoking its operation closewindow(), which in turn calls OUT_PORT(act)→cmd_closewindow().

Adapt TestScenario „storm“ of TestCase SD_tc_storm appropriately....

19Code Test Case

1 2 3Select the test context „TCon_windowcontrol“ and choose from the context menu „Create Code TestCase“.

Rename the created test case to „Code_tc_setangle“ and open the feature dialog.

Replace body of „Code_tc_setangle” with the content of the implementation tab of the example function „tut_CodeTestCase1” provided in package „Tutorial_Prerequisites”.

To create a source code TestCase create a code TestCase and write the test code into the edit field under the implementation tab of the TestCase.TestConductor provides a set of pre-defined assertion macros which can be used in TestCases for checking conditions during test execution. The most prominent and most used Rhapsody-TestConductor-macro RTC_ASSERT_NAME takes a

name-parameter and a condition. If the condition (angle==expectedangle) evals to true the TestCase will pass.

20Code Test Case: Execution

1 2Select „Code_tc_setangle“and invoke „Update TestCase”, „Build TestCase” and „Execute TestCase” from the context menu.

In the execution window, select the assertion and invoke “Show Assertion” from the context menu in order to highlight the assertion in the model.

Execute the TestCase.The expression in our assertion in the code TestCase evaluates to false and the test case fails. Double-clicking an assertion in the execution window or choosing 'Show Assertion' from its context menu highlights the assertion in the test model.

3 Note that we were smart enough to encode the actual value of angle in the assertion name string.

21Code Test Case: Fix and Re-Execution

When executing the TestCase, we saw that setangle(10,0) in fact returned an angle of 90° instead of the expected opening angle of 30°. This means that windowcontrol fully opens the window at 0°C outdoor temperature in order to cool the room (for tdiff==10°C). But the opening angle of the window shall be adapted to outdoor temperature ranges. So we inspect the body of the setangle() operation:

It turns out, that in the else branch of the angle calculation (if tdiff >6°C), a division by the coolingcorrection value calculated above is missing.For outdoor temperature of 0°C, a coolingcorrection value of 3 is determined by the algorithm. Hence, the returned angle has to be 90/3 instead of 90.We fix this by modifying the else branch (line 25) to: angle=90/coolingcorrection;

22Code Test Case: Fix and Re-Execution II

1 2Select „Code_tc_setangle“and invoke „Build TestCase” and „Execute TestCase” from the context menu.

Now the TestCase passes.

Re-Execute the TestCase.After we fixed the body of the setangle() operation, we have to build the test application again in order to reflect the changes.

3 The actual return value of setangle()adheres to the expectation.

23Code Test Case: Testing with Test Data

So far we used a code TestCase to test a single return of one invocation of an operation. Code TestCases can, of course, be used for more complicated tests.We will now create and execute a code TestCase, which aims at testing all relevant in- and outputs of setangle() according to a set of test data.

1 2 3Select the test context „TCon_windowcontrol“ and choose from the context menu „Create Code TestCase“.

Rename the created test case to „Code_tc_setangle_loop“ and open the feature dialog.

Replace body of „Code_tc_setangle_loop” with the content of the implemen-tation tab of the example function „tut_CodeTestCase2” provided in package „Tutorial_Prerequisites”.

24Code Test Case: Testing with Test Data II

1 2Select „Code_tc_setangle_loop“and invoke „Update TestCase”, „Build TestCase” and „Execute TestCase” from the context menu.

In the execution window, you can see, that each iteration tested the operation setangle() with a set of inputs and an expected return value.

Execute the TestCase.The TestCase defines an array of 24 triples – each triple consisting of a value for tdiff, for odtemp and one value defining the expected return of the respective setangle() invocation.This way, an operation can be tested for its characteristic behavior.

25Flowchart Test Case

Flowchart TestCases have the same expressiveness as code TestCases, but offer an intuitive graphical formalism to define the control flow of a test procedure.

1 2 3Select the test context „TCon_windowcontrol“ and choose from the context menu „Create Flowchart TestCase“.

Rename the created test case to „FC_tc_setangle“ and open the feature dialog. Select all elements in the diagram of FC_tc_setangle and delete them.

Open the diagram of „tut_FlowchartTestCase” provided in package „Tutorial_Prerequisites”, select all elements in the diagram and copy them to the diagram of FC_tc_setangle.

26Flowchart Test Case: Testing with Test Data II

1 2Select FC_tc_setangle“and invoke „Update TestCase”, „Build TestCase” and „Execute TestCase” from the context menu.

No surprise:In the execution window, you see a very similar list of assertions as for execution of the equivalent code TestCase.Flowcharts offer an intuitive graphical formalism for defining control flow in a procedure.

Execute the TestCase.The TestCase does exactly the same as the code TestCase Code_tc_setangle_loop.

27Quality of Tests: Coverage Measures

Besides testing functional aspects with individual TestCases, testing often has to meet generic quality requirements, such as „all model elements shall be activated at least once“ or „the generated code shall be covered to a certain degree“.

Among other quality mesures and coverage criteria, TestConductor offers measuring● Model Element Coverage● Code Coverage

These quality measures obviously play their role in different phases of model based development and model based testing. Model element coverage measures quality and completeness of testing in terms of the model and, hence, plays a more important role in earlier phases of the development process, where model quality is the major focus. In contrast, code coverage measures become important in later phases of development, where development activities focus on code quality.

Model coverage measure requires animation instrumentation of the test application, whereas code coverage in general shall not take animation instrumentation into account.

28Measuring Model Coverage

1 2 3Navigate to the <<TestingConfiguration>> code generation configuration of the test architecture and open its features dialog.

Check tag „ComputeModelCoverage“ on the 'Tags'-tab of the features dialog.

Invoke „Execute TestContext“ from the context menu of TCon_windowcontrol in order to execute all TestCases in one sweep.

To enable model coverage measurement, only a tag in the code generation configuration of the test architecture has to be checked.Make sure that model animation is feasible in your environment.

29Measuring Model Coverage II

After TestContext execution, you will find a cumulative model coverage report below the TestContext, as well as individual model coverage reports below each of the executed TestCases.The report shows in categories Operations, EventReceptions, Statechart elements the covered and uncovered model elements. Clicking the name of an element highlights the element in Rhapsody.

1Open the cumulative TestContext model coverage report.

30Measuring Code Coverage

1

4

Navigate to the <<TestingConfiguration>> code generation configuration of the test architecture and invoke „copy” from its context menu.

Rename the copied code generation configuration to „CodeCov“

In the „Tags“ tab of CodeCov reset tag „ComputeModelCo-verage” and check tag „ComputeCodeCoverage“

To enable code coverage measurement, basically also only one tag in the code generation configuration of the test architecture has to be checked. Since we want to measure code coverage for a none instrumented code generation configuration, we copy and modify the code generation configuration used so far. This allows for easily switching configurations later on.

„Paste” the configuration on the code generation component.

2

3

In the „Settings“ tab of CodeCov set „Instrumentation Mode“ to „None“.

Now code generation configuration CodeCov is ready to be used.

5

31Measuring Code Coverage II

For code coverage measurement, the generated source code has to be instrumented by TestConductor. Property CPP_CG.{ENV}.CPPCompileCommand of code generation configuration „CodeCov“ is modified, such that TestConductor's code-annotation-tool is invoked before the compiler in the build process of the test application. After execution of the test application, the code coverage information for the executed TestCases is collected and a code coverage report is generated. In contrast to model coverage measurement, only one report is generated per test execution. If an individual TestCase was executed, the report can be found below the TestCase. If the entire TestContext was executed, the report can be found below the TestContext.

3TestConductor notices the modifications and prompts for „Update, Build and Execute“ confirmation.

2Invoke „Execute TestContext“ from the context menu of TCon_windowcontrol in order to execute all TestCases in one sweep.

1Set code generation configuration CodeCov as active configuration.

4After TestContext execution,the code coverage report can be found below the TestContext.

32Measuring Code Coverage III

The code coverage report provides detailed information about individual coverage criteria. For C and C++, MC/DC coverage consists of Decision-, Condition-, Function- and Switch-Case coverage.Moreover, Statement coverage and Relational operator coverage can be found in the report.

The colored source code page of the code coverage report gives a convenient to read overview of the code coverage. It is available via the 'Source Code' link in the upper right corner of the report.

33Measuring Code Coverage – Operation setangle()

The colored source code view of the code coverage report shows us that we already reached a good coverage of operation setangle(). This has, of course, been achieved by the code TestCase Code_tc_setangle_loop and the flowchart TestCase FC_tc_setangle, respectively. For improving the code coverage, we are obviously lacking a TestCase for which the call of OUT_PORT(act)→cmd_setangle(angle) in line 336 returns something different from err_no_error.

If we reconsider the model coverage report we obtained for the same set of TestCases, then we will notice, that evError has not been received in our TestContext execution and thus also the errorstate in the statechart of windowcontrol has not been entered.

Note that for code coverage measurement, macros are expanded in the colored source code view. So line 336 ff in the colored source code view of the report corresponds to the original source code lines shown below:

34

Completing Code Coverage for Operation setangle()

1Create a SD TestCase and rename it to SD_tc_error.

We create a new sequence diagram TestCase with a stubbed return value for calling cmd_setangle.

2

Open the TestScenario of SD_tc_error and delete the life-lines of TC_at_rainevs_of_windowcontrol and of TC_at_storminfo_of_window-control. Arrange remaining life-lines, such that life-line of TC_at_inputs_of_windowcontrol is the left most, life-line of windowcontrol is in the middle and life-line of TC_at_act_of_windowcontrol is the rightmost life-line.

4

Edit the argument values in the Arguments-entry of the features dialog of the message.

5Now draw a message from itsWindowcontrol to itsTC_at_act_of_windowcontrol and set its realization to cmd_setangle(int).

3

Draw a message from itsTC_at_inputs_of_windowcontrol to itsWindowcontrol and set its realization to evTDiff(int,int)

6

Edit the argument value and the return value in the respective entries of the features dialog of the message.

3

Draw a message from itsTC_at_inputs_of_windowcontrol to itsWindowcontrol and set its realization to evTDiff(int,int)

35

Completing Code Coverage for Operation setangle() II

The resulting TestScenario of our TestCase now looks like depicted on the left. TestConductor will generate a driver operation for the evTDiff(tdiff=10,odtemp=0) message, which sends an „evTDiff“ event with the specified argument values via port connection from „itsTC_at_inputs_of_windowcontrol“ to „itsWindowcontrol“. When processing this event, „itsWindowcontrol“ will invoke its setangle()

operation.As we have seen before, setangle() will compute an opening angle of 30° and then invoke cmd_setangle() in „itsTC_at_act_of_windowcontrol” via port connection from „itsWindowcontrol” to „itsTC_at_act_of_windowcontrol”. We, hence, have to send an „evTDiff“ event to windowcontrol in order to trigger invocation of setangle(), which in turn will call OUT_PORT(act)→cmd_setangle(). By specifying return err_motor_stuck for the call of cmd_setangle() in TestComponent „TC_at_act_of_windowcontrol“, we force TestConductor to generate a stubbed cmd_setangle() operation in „itsTC_at_act_of_windowcontrol“, that will:● check, whether the message is received in the expected position,● check, whether the angle argument is 30 as specified in the TestScenario,● return err_motor_stuck according to the TestScenario specification.

36

Completing Code Coverage for Operation setangle() III

Due to the returned err_motor_stuck value, operation setangle() of windowcontrol will then generate an evError event (covering statements in our code coverage result that weren't covered yet), which will trigger windowcontrol to enter the errorstate.Note that windowcontrol does not observably indicate entering the errorstate to outside. We nevertheless want to capture our expectation in the TestScenario and establish an explicit check for this reaction. Therefore we use a so-called TestCondition. Since the condition we want to check becomes not immediately true as reaction on the return value, we need to add a TimeInterval to enforce a delay.

Add a TestCondition to the TestScenario.

1

Enter the condition to be checked in the Condition entry

2

The state change to errorstate in reaction to the internal evError event will not take place immediately. So we need some delay to let the state change take place.

3

To let time pass before checking the state change as reaction to the return value, we add a TimeInterval with a minimum duration of 200msec

4

37

Completing Code Coverage for Operation setangle() IV

Now the TestCase is ready to execute. We first execute the entire TestContext with our active „CodeCov“ code generation configuration and inspect the code coverage report for that execution. We will see that the setangle() operation will be almost totally covered. Only a few cases in the expanded OUT_PORT() macro will be still uncovered. To cover these cases, it would be required to disconnect the port connection from „itsWindowcontrol“ to „itsTC_at_act_of_windowcontrol“. Since this does not conform to the intentions of the model, we decide to live with this missing coverage items due to safe programming.

3

Rhapsody's code generation notices that the annotated source code due to code coverage instrumentation is newer than the latest model modifications and offers roundtripping.Say „No to All“.

31


2


38

Completing Code Coverage for Operation setangle() V

All TestCases passed.We open the code coverage report again and inspect the setangle() operation in the colored source code view:

Now covered!

39Completing Model Coverage

Finally, we re-execute the TestContext for the animated code generation configuration and verify that our latest TestCase also improves the model coverage. Navigate to our animated

code generation configuration DefaultConfig and set this configuration as active configuration.

1 2


3


4

Also for the animated code generation configuration all TestCases passed.We open the TestContext model coverage report….

… and verify that also the errorstate as well as the reception of evError (and transition 13 leading into the errorstate) are now covered.

5

40Treatment of messages

For completing the coverage of the setangle() operation, we used the powerful feature of TestConductor to automatically generate stubs for specified message returns.

SUT TestComponent

SUT ● message is ignored in black box testing.

● message and arguments and returns are checked in grey box testing.

● message order is checked.

● in-arguments are checked.

● if return or out-arguments are specified, stub will be generated returning/providing the specified value

TestComponent ● message is driven.● in-arguments are provided

according to specification.● if return or out-arguments

are specified, actual values will be checked against specified values.

● in general irrelevant

cmd_setangle() is called in TestComponent „TC_at_act_of_windowcontrol“ via windowcontrol's out-port act. TestConductor automatically generates a stub-function in TestComponent „TC_at_act_of_windowcontrol“ that will return the specified value for this message from SUT to TestComponent.

The table gives a brief overview, how TestConductor treats messages depending on their source and target.

For our purpose, it is important to know, that we only have to specify a TestScenario in which cmd_setangle() returns an indication other than err_no_error in order to let windowcontrol enter its errorstate.

tofrom

Conclusion

The high-grade automation in the Rhapsody Testing Environment with TestConductor

generates complete, immediately executable test architectures in shortest time with a few mouse clicks.

makes it for the first time possible to implement cyclically quality assurance measures in early phases of the development.

increases substantially the planning reliability for projects, because design errors and subsequent errors will be recognized very early.

makes statements about the coverage rates for both the model elements and model code. Developers can easily and fast analyze reasons for not covered elements.

highly automates the testing process and can save test development time compared to traditional approaches.

rhapsody in c++ tutorial - ibmtutorial for ibm ® rational® rhapsody® testconductor add on 2...

Documents