In the age of Software Defined Vehicles (SDVs), the way we develop, and test automotive software is undergoing a fundamental shift – both technologically and philosophically. One of the most impactful paradigms driving this change is the Shift-Left testing principle, which emphasizes testing earlier in the development lifecycle to catch bugs sooner, reduce costs, avoid recalls and improve software quality. For reference, here is an interesting article from my colleague Wolfgang Meincke explaining Why Shift-left testing is not just a buzz world but a necessity. Within this approach, unit testing plays a foundational role which I am happy to explain in this blog article.
Could Unit testing have prevented the TCM Software recall of General Motors?
In late 2024, General Motors issued a recall (NHTSA 24V-839) affecting certain 2022-2023 Chevrolet Express and GMC Savana vehicles. The issue was caused by a miscalibrated Transmission Control Module (TCM) software, which could lead to harsh shifting, reduced propulsion, or even unintended vehicle movement at low speeds, under certain electrical failures. This raised an important question for software and systems engineers: Which of the unit testing, integration testing, system testing or vehicle testing could have caught this issue?
Imagine a symphony orchestra, where each musician plays their part to create a harmonious performance. Most of the time, if one musician makes a small mistake, the collective sound of the orchestra can mask it. But when the music calls for a solo or a spotlight moment – when that one instrument takes center stage -, any error becomes immediately noticeable, disrupting the entire harmony.
Unit testing ensures that each component of the software functions correctly contributing to the seamless operation of the entire system – the harmonious performance. In contrast, integration, system, or vehicle-level testing may obscure defects originating from faulty individual units, making early detection more difficult.
Coming back to our example, if the calibration logic within the TCM software had been modular and testable, well-designed unit tests could have simulated the electrical fault conditions at low speeds, and validated the software’s response to ensure it aligned with safety and performance requirements priorily derived from a safety analysis (See an example of safety analysis in this article ISO 26262 Requirements Type). If the issue was due to incorrect parameter values rather than faulty logic, it might have been necessary that those values were explicitly validated, for example using equivalence class testing or formal methods that stressed the TCM against the undesired safety effects. These are typically part of exhaustive unit testing helping to catch up edge cases and performance issues.
What makes Unit Testing a foundation in Shit-left testing?
The core idea behind shift-left testing is to move testing activities as early as possible in the development lifecycle, and unit testing is the earliest and most granular form of testing available. By focusing on individual software components, unit testing allows developers to detect and resolve defects at the source – literally during development – before these issues propagate into more complex integration or system-level problems. This early detection is not only more cost-effective, but it also significantly simplifies debugging. When a test fails at the unit level, the scope of the problem is limited, making it easier to identify and fix the root cause.
Moreover, robust unit testing lays a solid foundation for efficient integration testing. When individual components are thoroughly tested, integration efforts can focus on verifying interactions between modules rather than uncovering basic functional bugs. This layered approach enhances the reliability and maintainability of the overall system, and ultimately create a foundation for the validation of the vehicle digital twin which is a pre-condition for Over-The-Air Updates.
In essence, unit testing embodies the principles of shift-left testing by enabling early, efficient, and scalable quality assurance acting as the first quality barrier. It helps teams to build better software faster, with fewer surprises late in the development process which is necessary for the development of Software-Defined Vehicles.
Could we rely on conventional or in-house testing frameworks for efficient unit testing?
Given the high complexity inherent in Software-Defined Vehicles (SDVs), traditional test frameworks and in-house tools often struggle to meet the demands of modern automotive software development. These solutions typically lack the scalability, traceability, and tool qualification required for safety-critical applications guided by standards like ISO 26262.
Consider the well-established testing framework Google Test. While it is a popular and flexible unit testing framework for C/C++, it often faces several challenges. Google Test does not align well – by construction (i.e. indirect mapping to the panel of testing methods) or due to its extreme openness – with the requirements of safety standards like ISO 26262, making tool qualification difficult. Additionally, essential testing features such as bi-directional traceability with requirements, code coverage and robustness analysis, and structured reporting are missing. These gaps typically require additional tooling or manual effort to integrate everything. Moreover, Google Test doesn’t integrate with model-based development workflows nor with on-target testing. Therefore, scaling it across large, safety-critical projects can lead to major maintainability issues.
Similarly, in-house tools based on Excel, scripting, and similar approaches may offer flexibility but often come with high maintenance costs, limited documentation, and poor integration with CI/CD pipelines.
Moreover, conventional frameworks generally do not support advanced testing techniques such as equivalence class testing, boundary value analysis, automatic test generation and formal verification, which all turn to be highly valuable for complex and safety-critical software.
Without robust test management, automated reporting, and tool qualification, these approaches can become bottlenecks rather than enablers – hindering the shift-left strategy and slowing down the path to safe, reliable, and update-ready vehicle software.
To explore this topic further, I invite you to read these two insightful articles: Why-you-want-to-use-industry-standard-tools and Four reasons to avoid writing test cases in Excel
Conclusion
In the context of Software-Defined Vehicles, unit testing is not just a technical necessity – it’s a strategic enabler of Shift-Left testing. By allowing early, automated, and scalable verification of individual software components, unit testing reduces dependency on late-stage testing, accelerates development cycles, and enhances software safety and reliability.
Whether the software is developed through model-based design or handwritten code, unit testing applies universally. However, implementing it effectively often requires more than conventional and in-house testing frameworks can offer. Challenges like test management, traceability, CI/CD integration and tool qualification can hinder progress. This is where professional testing tools come into play – bridging the gap with integrated solutions that streamline the process and ensure compliance with industry standards.
At BTC Embedded Systems, we bring over 20 years of expertise in automotive software testing to help teams overcome these challenges. Our solutions are built to support the evolving demands of SDV development, enabling qualified, efficient, and future-ready unit testing.
Want to learn how we can help you implement robust unit testing for your automotive software? Let’s connect, we’d be happy to share more.
