Modern Unit Testing for Safety- and Security-Critical Software With GoogleTest

Your comment raises an interesting point about simple test harnesses and GCC’s newer MC/DC support, but it oversimplifies the problem. Safety-critical verification is not just about executing assertions or collecting coverage. Teams also need structured test management, repeatable results, requirements traceability, coverage analysis, compliance reporting, and evidence that can withstand review. GoogleTest can be replaced by a basic harness for simple cases, but that does not provide the same scalable or audit-ready workflow. Likewise, GCC MC/DC support is useful, but it does not by itself solve tool qualification, traceability, reporting, or compliance evidence requirements.

GoogleTest can be replaced with simple main() test_fun1() assert(valid);
MC/DC is built into new gcc.
Also, requirements needs testing, not enough coverage means you don't have enough requirements.

You raise a very important point, and I realize now that when I referred to “requirements traceability,” I unfortunately was not clear enough about the distinction between requirements management and verification traceability.

What you are describing is exactly why organizations use dedicated ALM and requirements management platforms such as IBM DOORS Next, Codebeamer, Polarion ALM, Jama, etc.
Those platforms are responsible for managing:
• System requirements
• Architecture and design decomposition
• Derived requirements
• Requirement hierarchies and relationships
• Change management
• Impact analysis
• End-to-end traceability across the engineering lifecycle

So in your example:
System Requirement → System Design Decision → Derived Requirement → Software Architecture → Module Requirement → Code/Test
That chain is absolutely valid and critically important in real embedded and safety-critical development.

Parasoft is not attempting to replace that process or the ALM/requirements management platform managing those artifacts.
Where Parasoft fits is lower in the lifecycle, specifically around the realized verification and implementation artifacts like GoolgleTest test cases or unit test cases that exist outside the ALM tool itself.
For example:
• Source code implementing requirements
• Unit tests validating requirements
• Structural coverage evidence
• Static analysis findings
• Executed test results

Those artifacts are created and maintained in development environments and CI/CD workflows, not typically authored directly inside DOORS Next, Polarion, or Codebeamer.
What Parasoft provides is the ability to:
• Associate/link test cases with requirements
• Associate/link code with requirements
• Maintain those traceability links automatically during development and CI/CD execution
• Export/synchronize those relationships back into the ALM ecosystem

So the workflow becomes something more like:
ALM Tool:
System Requirement
→ Derived Requirement
→ Software Requirement
→ Design Relationships
Parasoft:
Software Requirement
↔ Test Case
↔ Test Execution Results
↔ Coverage Evidence
↔ Source Code Implementation

Then those links and verification artifacts can be synchronized/imported back into the ALM tool, enabling bidirectional navigation and helping fulfill the traceability matrix expected by standards such as:
• ISO 26262
• DO-178C
• IEC 61508
• IEC 62304
• EN 50128 / EN 50716

So to your point, yes, if a tool ignores the decomposition and derived requirement chain, it quickly becomes unusable in real systems engineering.
What often goes wrong is exactly what you described:
• Requirements linked directly from high-level system requirements to low-level code
• Missing architectural rationale
• Derived requirements improperly promoted into system requirements
• Loss of design intent
• Traceability that technically exists, but is semantically meaningless

Instead, the intent is to integrate with the ALM/requirements ecosystem and extend traceability into the actual software verification and implementation activities that occur outside the requirements management tool.
So the ALM platform remains the authoritative source for:
• Requirement decomposition
• Derived requirements
• Design relationships
• Systems engineering structure

While Parasoft helps automate and maintain:
• Requirement-to-test traceability
• Requirement-to-code traceability
• Verification evidence
• Coverage mapping
• Compliance reporting

Cheers!
rcamacho@parasoft.com

You mention the tools ability to link the code to requirements several times.
That's fine, but can it handle the "requirement -> design -> derived requirement -> design..." chain?

I've seen several tools that wanted to enable linking from code to requirement.
They all failed because they ignore that there seldom is a direct link from system requirement to code implementation.
In real development, there is a set of system requirements, they lead to a lot of decisions on the system design.
The system design and the decisions therein creates a new set of modules/units. And a set of derived requirements to those modules/units.
Those modules may be broken up into smaller units, introducing yet another layer of decisions on design, and related requirements.

Example case:
system requirement is that device can operate at 50 deg. ambient temperature.
The design decision, is to add a variable-speed fan and a small heatsink, and a temperature sensor.
The derived requirement, is now that the fan must run at x speed at y temperature.
Those requirements leads to a software design with many modules, among them is a fan-regulator module, and a temperature-reader module.
The requirement to the regulator is now not a pure temperature to speed relation, but temperature reading to either fixed PWM duty or to a encoder feedback.
The requirements to the temperature reader module, is to convert from an ADC voltage to a temperature, and because it is safe SW, it also has to do some validation of the signal.

In cases like this example, what I often see is that all the design decisions is left in a document somewhere, and not included in the requirement tracing. Then one of two thing tend to happen:

1. The system requirement of 50 deg. ambient, is linked directly into the two modules, leaving future developers clueless as to how that requirement is implemented, in fact making this code into instant legacy code.

2. In lack of a better location a lot of the derived requirements is put back into the system requirements, so now the fan-speed is suddenly a system requirement. If you are lucky the fan-speed requirement is linked to the ambient temperature requirement, but the design decision of using a fan is not linked (the tool does not provide that feature). Suddenly future development of this product is constrained by what looks like a system/customer requirement to use a fan...

And this was a simple case ;-)

Imagine what happens when development iterates over a design element, and all those links to design decisions is either missing or misplaced as system requirements. It's not pretty ;-)