...
To explain how to use C++test to perform unit testing from Workbench, we will provide an example that walks you through the complete process of setting up the unit testing framework—starting from creating a new project and ending with reviewing unit testing results. For this example, we will use the “Timer” source code from the C++test examples directory (<C++test installation directory>/Examplesexamples/Timer).
Creating a New Project
...
- In the Project Navigator, right-click the Timer project context, then choose New> Folder from the shortcut menu.
- In the Folder panel, enter the name
src. - Click Advanced to expand the additional settings area.
- Select Link to folder in the file system.
- Click the Browse button, then use the file chooser to select the <C++test Install Dir>/Examplesexamples/Timer directory.
- Click Finish.
...
- From the Application Development perspective, go to the Project Navigator, right-click the Build Targets node, then choose New Build Target from the shortcut menu.
- In the Build Target panel, leave the default settings as is (the name should be the same as the project name [Timer] and the build tool should be Linker), and click Next.
- In the Content Definition panel, select src, then click the Add Recursive button to add the entire src directory to the build target definition. This will be the source base for the testing process. The current contents of the Project Navigator are shown in the right side.
- Click Finish.
- Choose Project> Build Project. The Standard Workbench build procedure will start.
| Info | ||||
|---|---|---|---|---|
| ||||
When you are configuring the build for a project that will be unit tested with C++test, it is important to realize that C++test generates test components into the main project directory, but you don't want these test components to become a part of your original project build. That's why your build configuration should be organized in such a way that the C++test-generated directories (for example In short, C++test-generated test components are not designed to be a part of your original application. Test components are managed by C++test during the testing process only. For projects with Standard build support, C++test automatically excludes the generated test components from the original build. No additional action is required. For Flexible build support, this automatic exclusion is not supported and should be done manually. To exclude C++test generated directories from the build, you need to locate these directories in the build target definition, select them one-by-one, right-click the selection, and choose Exclude from build target from the shortcut menu.
|
Generating the Test Cases
...
- Duplicate the appropriate Test Configuration to the User-Defined area.
- Open the Execution> General tab.
- In the Test execution flow box, select Custom flow.
- Note that this requires the Embedded Support license option.
- Click the Edit button to the right of the Test execution flow box.
- In the Custom Flow dialog that opens, select Build test executable for VxWorks (RTP) – File Channel on PassFS (license required) or Build test executable for VxWorks (RTP) – File Channel on TSFS (license required) from the Available built-in test execution flow box, then click Restore.
...
The test execution flow definition will display in the main area of the Custom Flow dialog. At this point, you probably want to modify the flow step which controls the communication channel definition.
...
Once you have made all required modifications, you can run the customized Test Configuration that defines your preferred flow. After the Test Configuration is done running, the test executable binary file will be available. Before the test executable is started, run the "Utilities> Load Test Results (Sockets)" Test Configuration. Then, after this executable is started on the target device or on the simulator, the two ports will be opened for sending the test and coverage results.
| Note | ||||
|---|---|---|---|---|
| ||||
For collecting results via the socket communication channel, you need to start this Test Configuration before you start the test executable. Otherwise, the Test Configuration will hang waiting for results to arrive on the specified ports. The results collection is performed via a simple listening agent (written in Java) which is capable of listening on the given port and writing the data from this port to a file. The source code of this listener, together with its compiled versions, is located in |
...
After your results have been successfully loaded into Workbench, you can analyze them, generate reports, and modify the test cases accordingly. For details, see:
...
All Workbench-related recipes contain some initial properties to be set or adjusted, like the preferred toolchain or Wind River Shell executable. You may choose between the provided options according to their comments or redefine the values for your needs. The initial echo steps are there to present you console messages reminding you about this during testing.
| Note | ||||
|---|---|---|---|---|
| ||||
When using 'PassFS' communications on Windows hosts, you must prepend the paths of result logs with the 'host:' prefix. When using 'TSFS' communications, use the '/tgtsvr/' prefix. For more information on VxWorks features refer to the Workbench documentation. |
There are two options for testing DKM projects: simple and full.
...
The full option allows full unit testing, but requires the external symbol list to be provided during Test Module creation. The external symbol list must contain all the exported/defined kernel space symbols from the VxWorks image used inside your DKMs.For information on how to create the external symbol lists, see Providing an External List of Library Symbols.To build a Test Module using this approach, use one of the default "Builtin> Embedded Systems> Wind River> Workbench> Build VxWorks Test Module - DKM" Test Configurations.
...
To read the results use the "Utilities> Load Test Results (Files)" Test Configuration.
| Tip | ||
|---|---|---|
| ||
For more information on Test Flow Recipes, which you may need to customize in order to achieve the expected testing results, see Customizing the Test Execution Flow. |
...
To build and run your application in the application mode, use one of the all-in-one (excluding library symbols extraction) "Builtin> Embedded Systems> Wind River> Workbench> Run VxWorks Application with Mem Monitoring - DKM" Test Configurations. There is one for PassFS and one for TSFS communication.
...