GCC Code Coverage
Given the number of users of GCC, there is few tools which meet the needs of embedded developers today to do code coverage analysis in general and GCC code coverage specifically. This will change in the near future and here is how it will change.
Testing and optimization require the user to know:
- cold spots in the code, or code that is never executed and therefore untested
- hot spots in the code, or code that is executed very often, where a performance improvement will make a substantial improvement in performance
- boundry value testing of interfaces
- error guessing tests for specific algorithms
- branch testing (if a white box or grey box test approach is used)
- range or pattern analysis (common in digital signal processing where the actual results are within a pattern range)
- user interface testing and retesting
- Unit testing, subsystem testing, system or design testing, requirements testing and operational testing.
Code coverage is a small part of overall testing but usually where people start their unit testing to ensure high quality components and high performance components. There are a few free and available tools to do this but they are not universal and do not address the broader issues here. Ideally, C and C++ testers for embedded systems want something far more comprehensive.
Eclipse has a testing project and it has matured quickly for Java. It is currently not available for C and C++ (the CDT 4) but when it is it will offer much more of the broader functionality that is required. GCC code coverage analysis will be included at that time.
