When speaking of C programs, the term "component testing" - also sometimes referred to as "unit testing" - applies to the testing of functions. A function is passed a possible set of inputs, and the output for each set is validated to ensure accuracy. This can be done with either a single function, a group of unrelated functions, or with a sequential group of functions - i.e. one function calling another, verifying the overall or integrated, result.
Sounds simple but, unfortunately, in the embedded world its practice can be quite difficult. Why?
What if the function you wish to test relies on the existence of other functions that have not yet been coded?
How will you call the function-under-test in the first place?
How will you create and maintain a variety of potential inputs and associated outputs - that is, how will you make data-driven testing manageable?
What kind of effort and knowledge is required to run the test on your target architecture - that is, in the intended, native environment?
The component testing feature of IBM Rational Test RealTimePurifyPlus RealTimePurifyPlus for Linux for the C language provides a means for automating and verifying the above concerns. Through source code analysis:
Yet-to-be coded functions and procedures are "stubbed"; in other words, these functions are created for you
A test driver is generated to facilitate communication between your running code and the test
A test harness, independent of your test, is constructed to ensure adoption of your target architecture and thus enabling in-situ test execution
Plus, thanks to a powerful test script API:
Define stub responses to varied input generated by the function(s) under test
Enable highly detailed data definitions for data-driven testing
With the assistance of the Target Deployment technology, the end result is an extensible, flexible, automated testing tool for component and integration testing.