We were approached by a client who was developing a safety-critical project according to the IEC 61508 functional safety standard. We were asked for guidance on increasing developer productivity by further reducing the distractions created by unit testing due to the lack of stubbing.
We learned that the way customers approach unit testing is closer to integration testing. In their process, the unit to be tested is not isolated from its dependent components (other files or functions in the project), unit test cases are executed against most of the completed application.
This approach is not a typical unit test. It is often called integration level testing. Integration tests are very effective in demonstrating good test coverage of functional and non-functional requirements. It also provides excellent test coverage if structural code coverage is enabled. Why in-test stubbing improves integration testing
What is piling in tests?
The practice of unit testing is usually to isolate a function, method or procedure. This isolation is accomplished by weeding out dependencies and enforcing specific execution paths.
Stubbing replaces code that depends on outside this function. It also provides developers or testers with the ability to manipulate the pile driving response or results in order to employ the unit in various ways and for various purposes, for example, to ensure that the unit performs reliably, is safe, and in some cases, does not security breach.
Why use piling?
The best way to explain why you should use piling and the value it brings is to walk through a use case. For example, look at the following code:
At the beginning of the function, there is an if statement that tests whether the sample buffer was allocated successfully. Most of the test cases for this function are implemented without any stubbing, since they focus on normal control flow, except for the test case, which checks the behavior of the function when buffer allocation fails. This test case requires stubbing of the allocateSampleBuffer function to simulate a failure.
Once stubbing is added, it will be applied consistently to the test code. Users who are dealing with "allocation failure" test cases will have an easy way to install a special callback function into stubs which will simulate the desired effect: either fail the allocation or do nothing, since by default stubs return a A null pointer, which is expected for a test case. But all other test cases now need attention because a stubbing configuration has to be added for them to avoid unnecessary changes in the control flow.
Of course, developers can go back and reconfigure their test cases to solve stubbing, but this means spending extra time analyzing the cause of failures, preparing dedicated callback functions for stubbing, and eliminating interference during testing. Main concerns when contacting us.
In addition, risk management in medical device software development also requires an in-depth understanding of the extent of harm that medical software defects can cause. This can be done with a risk index, which categorizes risks according to their severity.
In the context of medical device software, establishing a risk index can help determine risk management metrics such as the level of testing, verification, and validation required before the software is released for use. It can also help set the tone for the ongoing testing, monitoring, and maintenance needed to ensure the continued security and effectiveness of the software.
Using stubbing in unit testing C and C++ code
Parasoft C/C++test makes it easier to automatically generate stubs or create stubs manually. This option is available in two places:
1. For automatically generated pilings :
Test Configuration -> Execution -> Symbols (tab)
2. For user piling and automatic piling:
Piling settings panel of the Piling view
Parasoft C/C++test changes how stubs are generated by default when the "Insert calls to primitive functions" option is checked . Stubs generated with the new options will act as proxies and call the original function definition, unless the user provides a test case-specific callback function to perform alternate activities.
By default, stubs generated without the new options (including legacy stubs) do not attempt to call the original symbols. If no test case-specific callback function is installed, stubbing will do nothing but return a default value such as a null pointer or zero value.
When to Use Piling?
To make sure the difference is clear, let's compare the situation with the "Insert call to original function" option enabled and not enabled when the user does not provide a dedicated callback.
This is stubbing for goo functions without the "Insert calls to original functions" option enabled. It works like this:
Here's how the same stub generated for a goo function looks when the "Insert calls to original functions" option is enabled:
As we can see, the stubbing added with the new option is transparent to the test code. They just perform a proxy call to the original definition, unless someone provides callback code for an alternate action.
Piling limitations and difficulties
What happens in cases where the piling function has no original definition? How would stubbing behave without defining callbacks for alternative behavior?
The neat thing about C/C++test is that it automatically detects this situation. During test builds, stubbed functions, i.e. user stubs, will reconfigure themselves. When no callback is installed, it will not call the original definition and will return a safe default.
Stubbing in Integration Tests: Examples and Summary
In this kind of semi-integration testing, C/C++test greatly reduces the interference between different team members when processing test cases at the same time. The stubbing code added by developer A does not change the behavior of the test code for the test cases added by developer B.
If Developer B decides that they need to configure an alternate action for one of the test case's stubbing functions, they can create a test case-specific callback function, implement the desired alternate logic for the stubbing function, and configure that callback function as a test case Part of it is installed in the existing piling.
This avoids the problem of different people having different testing needs. If you are interested in the above content, please continue to pay attention to us,