Close

Testing C/C++ code with TPT

C and C++ code can be easily tested with TPT. Testing C or C++ code is possible for module and integration tests. Every piece of C/C++ code — small, big, or even integrated SW builds — can be tested with TPT. TPT masters your software tests and greatly simplifies creation, management, maintenance and analysis of tests. Software-in-Loop Testing with TPT can be easily automated and it integrates seamlessly into your test environment.

By default, TPT supports lots of common C or C++ code features and even less frequently used ones. For special requests TPT is also flexible to adapt to manual tweaks. TPT masters your C and C++ tests — and you save time to focus on your product development. SiL Testing with TPT is efficient testing.

Watch the tutorial.

SiL Testing of C and C++ code with TPT. How it works.

Test setup and execution of C or C++ code with TPT is easy. You only have to select your C/C++ sources and make a few configurations. TPT does the rest – if you like – fully automated in the background. The test harness that connects the C or C++ code with TPT will be generated automatically by TPT or can also be built manually. Its your choice.

C/C++ code analysis.

TPT analyzes the structure of your C or C++ code automatically. It extracts all data types, variables and functions to get all the interface information of the system under test. TPT handles scalar variables, arrays, multidimensional arrays, structs, pointers, maps, curves and class instances. Even fix point scaling is easily managed by TPT so that the tester operates with natural physical values.

Function calls and function stubs are also supported and generated by TPT allowing the user to control their return values and arguments.  The task scheduling with one or many C functions makes testing of your code very easy and flexible.

Functional Test case design.

Test cases can be modeled with TPT manually as functional test cases. TPT supports many awesome techniques for modeling tests. TPT test case design is very natural and intuitive including reactive closed loop testing, signal and parameter descriptions, measurement data playback and much more. Test structuring makes it simple to read for maintainability. It is really easy to create and easy to maintain tests for C or C++ code.
C Code Workflow

Tutorial: C code function stubbing.

Stub missing functions of your C code in TPT. You can easily analyze the sources used in your code and define any unresolved references. In this tutorial you can see how easy this can be done.

Structural test case design (TASMO).

For C and C++ code you can even generate test cases automatically. If you need test cases that meet certain coverage criteria such as Condition Coverage or Decision Coverage, TPT offers a technology — called TASMO — to generate suitable test cases at the push of a button. You just select the desired coverage criteria and TASMO searches for the test cases for you. TASMO generates a minimum number of test cases automatically that lead to a maximum structural coverage of your C or C++ code. The generated test cases can also be used for back-to-back regression tests and can be merged with your functional test cases.

Test harness = Generated.

TPT automatically generates wrapper code that encapsules your code and connects it to TPT. If needed, TPT instruments your code either to access non-public variables or to track coverage conditions.

Tools such as MinGW, GCC or Visual Studio can be used to compile the executable.

Test execution: Just run it.

You don’t have to care about all the details of test harness generation and test execution. It is as simple as pushing a button. TPT together with the generated test harness do all the work for you. TPT starts and controls the entire test execution.

You can even debug your C or C++ code during testing.

Complex test suites are welcome.

Complex C or C++ tests or test suites can be executed unattended in batch mode or by using the TPT Jenkins plugin, for example overnight. TPT can also remote control several execution instances in parallel which can significantly reduce test execution time.

Analysis, analysis, analysis.

After the test execution, TPT starts the test assessment based on the collected data for C or C++ variables and parameters. Also non-exported variables can be tracked by TPT and included in those assessments. Finally, a report of the results is generated.

C Code Back-to-back testing

Build your own test environment.

In case your code is very special and needs your own setup to run TPT has the option to build your own flexible environment yourself. Software-in-Loop testing with TPT is highly adaptable.

You just need to compile and link an executable program with the TPT VM (TPT’s virtual machine library) connected to your SUT. The API of the TPT VM comes with convenient functions for initialization, variable bindings and cyclic interactions between the TPT VM and your SUT code for the whole test that usually runs over a certain time.

With this API you can build your own test setup while using the strength of TPT test modeling, test execution, test assessment, test reporting, and test process support.

C code testing in the TPT FUSION co-simulation.

The FUSION co-simulation environment of TPT allows interaction of one or more “simulation modules” — called FUSION nodes. Off-the-shelf, many FUSION nodes exist that allow interaction with 3rd party software and hardware components. For special needs, the public API of FUSION can by used by customers to connect additional FUSION nodes.
As an example, you can test C or C++ code (compiled as a FUSION node) together with plant models implemented in Simulink or with interfaces to other 3rd party software or hardware (e.g. CAN connectors).

C-code testing using Eclipse CDT and GBD debugger.

Another great feature of TPT is the ability to test C or C++ code using an Eclipse CDT and GDB (GNU debugger) connector. Using TPT with Eclipse CDT and GDB allows to compile, test and debug C or C++ code. Remote control of the GNU Debugger makes debugging even easier and allows access to almost any variable in the code at runtime. The Eclipse CDT/GDB simulation can be controlled, observed and debugged directly and automatically via breakpoints and register accesses at runtime.

What is Software-in-the-Loop Testing? An Introduction.

If you want to learn more about SiL Testing, we have summarized the key aspects for you here. Find out about the central strengths of Software-in-Loop testing and its role as part of a model-based development approach

What's new?

FEY-Approach

Introducing the FEY-Approach

Discover how the Full-Expectation-Yet (FEY) Approach revolutionizes software testing by focusing on outputs and behavior validation. By ensuring the presence of expected values, this approach

Read More »