{"id":1767,"date":"2026-04-08T11:49:39","date_gmt":"2026-04-08T11:49:39","guid":{"rendered":"https:\/\/www.pickplace.de\/?post_type=glossary&#038;p=1767"},"modified":"2026-04-08T14:39:02","modified_gmt":"2026-04-08T14:39:02","slug":"code-coverage","status":"publish","type":"glossary","link":"https:\/\/www.pickplace.de\/en\/glossar\/code-coverage\/","title":{"rendered":"Code Coverage"},"content":{"rendered":"<p class=\"wp-block-paragraph\"><strong>Code Coverage<\/strong> refers to the measurable portion of program code that is actually executed by tests. The term originates from software quality assurance and is primarily relevant in software verification and validation. In embedded development, however, code coverage has a significantly greater practical importance than in many classic IT applications because here software is directly linked to physical hardware, safety-critical functions, and often hard-to-reach error scenarios.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Content<\/h2><nav><ul><li class=\"\"><a href=\"#wozu-braucht-man-code-coverage\">What is code coverage needed for?<\/a><\/li><li class=\"\"><a href=\"#code-coverage-fur-embedded-systems\">Code Coverage for Embedded Systems<\/a><\/li><li class=\"\"><a href=\"#sicherheitskritische-elektronik\">Safety-critical electronics<\/a><\/li><li class=\"\"><a href=\"#bedeutung-von-code-coverage\">Meaning of Code Coverage<\/a><ul><li class=\"\"><a href=\"#sichtbarkeit-fur-ungetesteten-code\">Visibility for untested code<\/a><\/li><li class=\"\"><a href=\"#nachweis-fur-fehlerbehandlung-und-robustheit\">Proof of fault tolerance and robustness<\/a><\/li><li class=\"\"><a href=\"#bessere-testpriorisierung\">Better test prioritization<\/a><\/li><li class=\"\"><a href=\"#4-unterstutzung-bei-refactoring-und-portierung\">Assistance with refactoring and porting<\/a><\/li><li class=\"\"><a href=\"#5-unterstutzung-fur-safety-und-security\">Support for Safety and Security<\/a><\/li><li class=\"\"><a href=\"#reduktion-von-scheinsicherheit\">Reduction of false security<\/a><\/li><\/ul><\/li><li class=\"\"><a href=\"#bewertung-und-metriken\">Rating and Metrics<\/a><\/li><li class=\"\"><a href=\"#zusammenfassung\">Summary<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"wozu-braucht-man-code-coverage\">What is code coverage needed for?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Code coverage essentially answers the question: Which parts of the code were actually reached by my tests? This isn't about whether the test \u201epassed,\u201c but whether specific statements, branches, conditions, or paths were executed at all.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Typical types of code coverage are:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Statement Coverage<\/strong><br>Measures which individual instructions have been executed at least once.<\/li>\n\n\n\n<li><strong>Branch Coverage<\/strong><br>Checks if both directions of a branch have been tested, for example <code>If<\/code> and <code>else<\/code>.<\/li>\n\n\n\n<li><strong>Condition Coverage<\/strong><br>Measures whether individual logical subconditions within complex expressions were true or false.<\/li>\n\n\n\n<li><strong>Path Coverage<\/strong><br>Consider complete execution paths through the code. This form is very complex, as the number of possible paths grows rapidly.<\/li>\n\n\n\n<li><strong>Function Coverage<\/strong><br>Measures which functions were called by tests.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">In many projects, code coverage is expressed as a percentage: \u201e85% % statement coverage\u201c or \u201e100% % branch coverage.\u201c At first glance, this figure seems clear-cut, but it is not, in and of itself, proof of quality. High coverage does not automatically mean good tests. It only shows that a lot of code was executed. Whether this code was tested with meaningful inputs, realistic error cases, and plausible boundary values is another question.<\/p>\n\n\n\n<div class=\"wp-block-stackable-image stk-block-image stk-block stk-fa0bbe9\" data-block-id=\"fa0bbe9\"><style>.stk-fa0bbe9 .stk-img-figcaption{text-align:center !important;font-style:italic !important;}.stk-fa0bbe9 .stk-img-wrapper{width:60% !important;}<\/style><figure><span class=\"stk-img-wrapper stk-image--shape-stretch\"><img loading=\"lazy\" decoding=\"async\" class=\"stk-img wp-image-1768\" src=\"https:\/\/www.pickplace.de\/wp-content\/uploads\/2026\/04\/branch_coverage.jpg\" width=\"60\" height=\"300\" alt=\"Code Coverage and Branch Coverage in Embedded Systems Projects\"\/><\/span><figcaption class=\"stk-img-figcaption\">Typical example of dead code<\/figcaption><\/figure><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">This is precisely why code coverage is often misunderstood. It is not proof of error-free operation. Code coverage is an analysis tool to reveal blind spots in the testing system, such as dead code. If certain code segments are never executed, then there is effectively no test assertion there. Without coverage measurement, this often goes unnoticed in many projects.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"code-coverage-fur-embedded-systems\">Code Coverage for Embedded Systems<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">For embedded systems, code coverage is particularly important because several boundary conditions come together there, making testing difficult:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">First, embedded software is often tightly coupled to real hardware. Parts of the code react to interrupts, timers, DMA, peripheral registers, communication frames, or error states of external components. Such situations often do not occur completely or only randomly during normal functional testing. Without coverage analysis, it remains unclear whether these sections have ever been tested.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Second, embedded systems often contain many exception and fallback paths. These include watchdog reactions, error handling for communication failures, voltage issues, memory errors, timeouts, invalid sensor data, or startup problems during the boot process. These paths are rarely visible in everyday use precisely because they are only activated under fault conditions. However, from a safety and reliability perspective, they are often more important than the nominal main path. Code coverage helps to check whether such error handling mechanisms have ever been deliberately triggered and tested.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Third, embedded products are often durable and operate in industrial, mobile, safety-critical, or harsh environments. Failures manifest not only as application crashes but potentially as device downtime, faulty readings, communication failures, or dangerous system states. In such environments, superficial functional testing is insufficient. The question of which parts of the code have actually been verified becomes a technical and often regulatory necessity.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Fourth, observability in embedded systems is often worse than in PC or cloud software. There is usually no complete logging, no convenient runtime inspection, and no easy reproducibility of all states. Coverage measurement creates an additional layer of transparency here. It shows what really happened on the target or in the test environment during a test.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sicherheitskritische-elektronik\">Safety-critical electronics<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Another important point is the role of code coverage in regulated or safety-critical development processes. In areas such as automotive, railway, aerospace, industrial safety, or medical technology, test coverage is often evaluated not only technically but also procedurally. There, coverage serves as proof that requirements and implementation have been systematically verified. This becomes particularly relevant in conjunction with standards and methods such as structural coverage, MC\/DC, or requirement-specific test case derivation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In an embedded context, a distinction is often made between tests at different levels:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Unit Tests on Host or Target<\/li>\n\n\n\n<li>Integration tests with real interfaces<\/li>\n\n\n\n<li>Low-level hardware tests<\/li>\n\n\n\n<li>System tests<\/li>\n\n\n\n<li>Fault injection or robustness testing<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Code Coverage can have varying value at all of these levels. A unit test often achieves good coverage in isolated modules, whereas hardware-dependent states are not represented there at all. A system test covers real-world workflows better, but often achieves specific rare branches less effectively. Therefore, coverage is especially useful when it is not viewed in isolation, but rather as a combination of multiple test levels. <\/p>\n\n\n\n<p class=\"wp-block-paragraph\">More on code coverage in a safety-critical context <a href=\"https:\/\/www.linkedin.com\/pulse\/das-am-meisten-missverstandene-thema-des-software-code-heininger-iohrf\/\" target=\"_blank\" rel=\"noopener\">in this post by Martin Heininger<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bedeutung-von-code-coverage\">Meaning of Code Coverage<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Why is code coverage specifically important in embedded projects?<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"sichtbarkeit-fur-ungetesteten-code\">Visibility for untested code<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In established embedded codebases, there are often old functions, legacy routines, special cases, or defensive programming parts that no one actively looks at anymore. Coverage makes visible which parts are included in the build but are never tested. This is particularly relevant for ported software, platform changes, or long product cycles.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"nachweis-fur-fehlerbehandlung-und-robustheit\">Proof of fault tolerance and robustness<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The most interesting bugs are often not in the nominal main path, but in special cases. Coverage shows whether recovery strategies, error flags, retry mechanisms, timeout handling, or safe state transitions have been tested at all.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"bessere-testpriorisierung\">Better test prioritization<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">When coverage data is available, test gaps can be specifically addressed. Instead of writing more arbitrary tests, the team can specifically look at unreached branches, conditions, or functions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"4-unterstutzung-bei-refactoring-und-portierung\">Assistance with refactoring and porting<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Especially with embedded<a href=\"https:\/\/www.pickplace.de\/en\/porting-and-refactoring\/\" data-type=\"page\" data-id=\"1313\">Portings<\/a> coverage is valuable for new microcontrollers, RTOS versions, compilers, or hardware platforms. It helps assess whether the existing test base still reaches the relevant code after the transition or if important paths have been lost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"5-unterstutzung-fur-safety-und-security\">Support for Safety and Security<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Even though coverage alone does not guarantee safety or security, it is an important foundation. Safety-relevant plausibility checks, authorization checks, secure boot decisions, error reactions, or communication validations should not only exist but demonstrably be executed in testing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"reduktion-von-scheinsicherheit\">Reduction of false security<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Many projects have extensive test suites, yet still have significant gaps. Without coverage, it's easy to get the impression that \u201ea lot has been tested.\u201c Coverage forces a sober assessment: What has actually been executed, and what hasn't?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bewertung-und-metriken\">Rating and Metrics<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">It is particularly important to distinguish between good and bad use of coverage. Bad use means optimizing solely for a target number, such as \u201ewe need 90 %.\u201c This often leads to writing trivial tests that merely touch a few lines of code but provide little meaningful insight. Good usage means using coverage as a diagnostic tool: Which security-relevant, error-critical, or hardware-dependent parts are still untested? Where are targeted negative tests missing? Which branches have never been reached?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In embedded systems, technical challenges also arise with coverage measurement itself. Unlike desktop software, the code often runs on microcontrollers with limited memory, restricted runtime observation, or hard real-time requirements. Instrumentation for coverage can alter timing, consume memory, or falsify certain effects. Therefore, it must always be evaluated where and how coverage is measured:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>on the host in a simulated environment,<\/li>\n\n\n\n<li>on the real target,<\/li>\n\n\n\n<li>with compiler instrumentation,<\/li>\n\n\n\n<li>about trace hardware,<\/li>\n\n\n\n<li>or in combination of different methods.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Every method has limitations. Host-based tests are faster and easier to automate, but often only incompletely represent register accesses, interrupt timing, or hardware errors. Target-based measurements are more realistic, but more complex and expensive. Therefore, a hybrid approach makes sense for many embedded projects.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Another aspect: not all code should be evaluated equally. In embedded projects, there are often sections that are difficult or only indirectly testable, such as startup code, compiler-generated code, hardware abstraction layers, exception handlers, bootloader parts, or diagnostic paths under rare hardware errors. These parts should not simply be ignored, but they often require separate justification. Good development processes therefore also document why certain areas were not covered by coverage or were only covered to a limited extent.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In the safety-related environment, the term \"structural coverage\" is also frequently used. This refers to the systematic analysis of which program structures have been activated by tests. Different requirements may apply depending on the standard. MC\/DC (Modified Condition\/Decision Coverage) is particularly well-known in this context, aiming to prove that individual conditions within a decision can independently influence the outcome. This is especially relevant for safety-critical logic, such as in protection functions, state machines, or enable mechanisms.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zusammenfassung\">Summary<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Code coverage is not an end in itself or a metric solely for management slides. In embedded development, it is primarily valuable because it makes visible the gap between existing tests and actually executed code. It doesn't show whether a product is good, but it very clearly shows where no robust test assertion currently exists.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Code coverage is a tool for evaluating test coverage at the code level.<\/strong> It helps to make untested instructions, branches, conditions, and error paths visible. It is particularly important in embedded systems because hardware-dependent states, exceptional cases, recovery mechanisms, and safety-relevant functions often cannot be reached automatically by standard tests.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For electronics and embedded development, this specifically means: Those who only test normal operation often fail to test the parts where systems fail in the field. Code coverage makes these gaps visible and is therefore a central tool for robust software, traceable verification, and reliable development processes.<\/p>","protected":false},"excerpt":{"rendered":"<p>Code Coverage bezeichnet den messbaren Anteil eines Programmcodes, der durch Tests tats\u00e4chlich ausgef\u00fchrt wird. Der Begriff stammt aus der Software-Qualit\u00e4tssicherung und ist vor allem in der Verifikation und Validierung von Software relevant. In der Embedded-Entwicklung hat Code Coverage jedoch eine deutlich gr\u00f6\u00dfere praktische Bedeutung als in vielen klassischen IT-Anwendungen, weil hier Software direkt mit physischer [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"menu_order":0,"template":"","meta":{"footnotes":""},"class_list":["post-1767","glossary","type-glossary","status-publish","hentry"],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":8}},"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1767","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/types\/glossary"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":2,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1767\/revisions"}],"predecessor-version":[{"id":1770,"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/glossary\/1767\/revisions\/1770"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/en\/wp-json\/wp\/v2\/media?parent=1767"}],"curies":[{"name":"WP","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}