I often write and test quite significant parts of code on a PC.

In an environment where the "main" application looks at inputs, sets outputs, picks up measurements and data from input ring-buffers and sends to output ring buffers, I can write code that uses TCP connections or threads to pick up data from outgoing queues and process, and to generate data and feed to input queues.

And when using a compiler that supports "inline", port access functions can be encapsulated into helper functions: "draw_relay0()" which is inlined to a port pin access on target hardware but interacting with the test bench code when testing on the PC.

Actual interrupts or peripherial code can not be tested in this kind of environment. But that isn't really a problem. The basic interrupt and peripherial code is just standard library code already tested and used by other projects. Additional business logic needed in an ISR is normally very trivial - maybe count down some timer variables, look for stuff characters in a data sequence to separate data into packets etc.

In the end, lots of business logic (which can be quite large) can be tested/debugged a long time before there exists any usable hardware. And the huge I/O bandwidth of a PC allows some tests that aren't practical to do in the real, embeddd, system. If working with a display controller software, the PC test bench can display the contents of internal display memory buffers in real time as the code draws text, images, ... Or when displaying scrolling/animating information, the test bench can capture frame-by-frame content and step forward/backward in produced output, to help spot drawing glitches that are too short to see on a real-target hardware with maybe 100Hz+ frame rate.

When testing communications code, a simulated environment allows the test bench code to introduce repeatable or random transfer errors to verify protocol recovery in a way that is hard/impossible to do with the real hardware.