A lot rides on the electric control units ECUs and the software that sits inside it. From the manufacturer’s reputation to the safety of the vehicle occupants, embedded software is powerful enough to leave an impact on these critical factors.
Hence, there is no scope for errors and bugs when you are developing automotive embedded software for critical vehicle ECUs.
So, as an automotive software developer, what should one do to ensure that the automotive ECU software is foolproof? Software Testing is your friend in need!
As the automotive software are quite complex with each module having several functionalities, the software testing process also gets quite tricky and time consuming.
Tools like Check C come to the rescue of the automotive software developers and the testing engineers like you, to ensure that you deliver quality products.
In this blog, we will talk about the capabilities of Check C tool and how this tool makes the unit testing process a little easier for the automotive software development team.
Overview of Check C, a Unit Testing Tool
Essentially, Check C is a software tool for writing and executing unit tests. However, there is more to what meets the eyes.
“Check C is an open source tool and this is one of the reasons why it so popular among the embedded software engineers. Ask any seasoned embedded software developer and they will tell you how special the tool is.”
It may not be an automated unit testing tool, but it can enable automatic execution for the unit testing processes. The fact that Check C is standardized also makes it a reliable tool for automotive ECU testing.
The Prowess of Check C as a Unit Testing Framework
Simplicity is a vital aspect of the frameworks that need to handle complex codes. Check C is a winner in those terms. It boasts a very simple framework for the testing team to define the test cases.
There is a separate address space where the tests are run. This leads to the detection of both code errors and assertion failure that may cause segmentation faults.
Also, Check C supports test reporting in following formats:
- XML
- Tap
- Subunit
- And a generic logging format.
Of these formats, XML has been the format of choice across the software testing community.
Features of Check C testing tool:
- Modifiable Code and Manual Scripting:For performing Unit Testing, as per statement coverage and branch coverage, the software testing team is required to write the scripts and codes manually.
Of course, Check C framework verifies the codes and scripts, but gives the developers the flexibility to write the test cases according to their understanding.
For instance, the code to generate the test report can be customized to support desired test report formats.
Let’s say one needs to add the hyperlink to the test reports. So that, in case of the failure of any test cases, the developer can simply click on the hyperlink and C file will open. This is possible to implement using Check C framework.
Also test reports that are generated as text files can be converted to XML files by writing simple scripts.
Manual Scripting also offers some advantages, for example, in case of code changes, the script used previously will not give 100% test coverage. This makes it easy to identify any issue with the new code.
- Check C APIs: Check C provides APIs for unit testing. Some of these APIs are Start Case-End Case, ck_assert_int_eq and more.
Here is a code snippet that clearly depicts how one of the Check C APIs, Start_Test, End_Test work
Each test case starts with START_TEST and ends with END_TEST. Similarly, other APIs have their functions clearly defined.
The Unit Testing Methods supported by Check C Tool
Statement Coverage: This method is also known as Line Coverage because in this method, the tool checks every executable line of the code once. The objective of statement coverage is to identify ‘dead codes’!
These are basically software codes that may have been written by the developer by assuming that certain condition will be fulfilled. However, during the execution of the entire function, such assumed condition is never satisfied and a specific set of code never gets executed (hence the name ‘dead code’).
Branch Coverage: It is a little in-depth unit testing method, in which ‘if..else’ branches are tested. It can happen that a developer misses to include the ‘else’ condition in the branch causing output anomalies.
Such errors can be easily identified by the branch coverage method. Branch coverage ensures that the branch is tested for both ‘true’ and ‘false’ scenarios. It helps in the validation of all the branches and mitigates any abnormal code behavior.
Calls Executed: This part validates internal functions or API calls within the code. It checks whether the right function is being called and also whether the function is giving the desired output.
Check C lets the software testing team input the parameters for API calls and validate the feedback/output based on those parameters.
Modified Condition/Decision Coverage (MCDC):Ideally, every piece of code should have an entry point and an exit point. However, any instance of multiple entry/exit points need to be identified and reported. Check C does this efficiently with MCDC.
Instances of misplaced break statement, pressing of ESC character and more will always lead to partially executed loops (certainly not desired and recommended).
Also, there may be a scenario when two or more conditions (say A & B) need to be met for a particular test case to be 100%. Statement and branch coverage will not suffice here as they check only one condition. If the first condition is true, it will not execute further.
These issues are identified by Check C using the modified condition/ decision coverage. To label a software code as “Tested Ok” for deployment in the production server, the percentage of statement, branch and calls executed is usually set at 100% and for MCDC, it is kept around 90%. This percentage can be specific to the projects and the safety criticality of the software component.
At times, even after running all the test cases, MCDC may be at 70-80%. Check C provides a Dot GCOV file that can help the developer understand which part of the code did not execute.
Shown below is a sample Unit test report and MC/DC code coverage report. The coverage percent along with other relevant info is mentioned
For Example: #### for the line/branch not executed
Taken 0- for MCDC coverage failure
Call 0- for call not executed
Features That Make Check C the Preferred Tool for Unit Testing
There are plenty of reasons why Check C is one of the most widely used open source unit testing framework. Following are the most striking features of Check C:
- A lightweight tool that uses same language and development environment as the developer
- Easy, systematic and a comprehensive method of organizing and executing the test cases
- Check C Framework code can be modified according to specific testing needs
- Reusable test functionality
- Customized test report generation
- Debugging the code using Dot GCOV file.
- Automated regression testing
These features bring along with them a host of advantages. We have enumerated some benefits of using Check C:
The Benefits of Check C as a Unit Testing Framework
- Code Robustness is ensured
- Run-time error can be avoided
- Open source nature reduces cost of development
- Modifiable code for flexibility
- Powerful tool as it simulates all test conditions
- Boundary value checking
- Dead code removal through various test coverage
- Functionality can be validated efficiently
Migration of Check C from Linux to Windows
Check C is originally written for Linux. However, it can be migrated to Windows and other operating systems too.
Migration to Windows OS is performed using Cygwin Software. It can be easily installed using the setup file freely available online on Cygwin website.
The image shows the commands needed to run to get this migration started
After the installation, you need to download the Check C source code which is open source and available on https://sourceforge.net/projects/check/files/latest/download.
A few commands on the Cygwin Terminal and you are good to go. A detailed tutorial for migration of Check C to Windows OS can be found online.
Final Thoughts
Check C as a unit testing framework does not attempt to be an automated unit testing tool. In fact, it aids the developer in executing the test cases in an ideal environment.
It allows the developer to add manual scripting and do the desired code modification. With a semi-automated flavor to the framework, it is just what the developers coding in C language require- power with flexibility!
