Because the application logic depends on an interface, not on hardware registers, you can implement that interface with a fake or mock that runs on a host PC, recording calls, returning canned values, and unit-test the logic by injecting the fake. For example, a Blinker that takes an IGpio& can be tested with a MockGpio that counts set/clear calls; you assert the logic drives the pin correctly without any MCU. This matters enormously: you compile and run the tests on your laptop and in CI in milliseconds, catching logic bugs without flashing a board, attaching a debugger, or even having hardware, which is slow, serial, and hard to automate. It shifts the bulk of firmware debugging from on-target to off-target. The discipline it requires is keeping logic decoupled from register access (behind the HAL), which is good design regardless. It's the single biggest practical reason to architect firmware around abstractions.
C++ for Embedded · Interview question
How does the HAL pattern make firmware testable, and why does that matter?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
The HAL Pattern
Abstract a peripheral behind an interface so app logic survives an MCU swap and runs in a PC unit test, using runtime virtuals or zero-overhead compile-time polymorphism.