Hi everyone. Today I want to share some progress on the human body simulation I'm working on.

The work is going much slower than I initially expected (yes, the classic programmer excuse), mostly because I have to do research on biology and physiology for almost every single component before I can even start coding it. Still, progress is progress. In this post, I want to focus on one specific topic: how I test the simulation.

Why testing suddenly matters

In my previous simulation projects (for example, a CAN bus simulation), things were simple enough that unit tests didn't feel necessary. If something was broken, it was obvious just by running the simulation and looking at the output.

With the human body simulation, this approach stopped working very quickly.

Now I have:

• a layered architecture,
• many interacting components,
• complex signal exchange patterns (including oscillatory signals with different frequencies),
• and eventually a UI on top of all that.

Another important point: the simulation is not only a human body. It's a whole environment with its own time, air, sun, and physical context. So before testing organs or physiology, I first needed to be sure that the most fundamental thing works correctly.

Testing time progression

The first thing I wrote tests for was time advancement inside the simulation.

Here is a simplified example of such a test:

And here is the helper function used to run the simulation:

How this testing approach works

The testing pattern is very simple:

1. Run the simulation. No REPL, no UI. Just the step-based simulation engine with FMesh inside it.
2. Observe signals we care about. In this case, we observe the tick signal produced by the global time component.
3. Make assertions on observed values. Here, we assert that simulation wall time is monotonically increasing.

To collect observed signals, I use FMesh hooks. Hooks allow injecting code at specific lifecycle points of a component. In this test, I attach a hook that runs after activation of the time component and inspects its output signals.

About sleeping in tests (yes, really)

Normally, sleeping or waiting in tests is considered an antipattern. It makes tests slower and does not guarantee a strict cause–effect relationship. You are essentially hoping that the system reaches the desired state within a given time window.

In this case, however, sleeping is not a workaround. It is the actual behavior being tested.

Let the simulation run for a while, then observe how it evolved.

That is exactly what a simulation is supposed to do. So something that would be questionable in regular application testing makes perfect sense here.

What kind of tests this enables

With this approach, it becomes very easy to write tests like:

• "After 100 ms of simulation time, the human must be alive"
• "The human cannot survive 15 minutes without oxygen"
• "At night, the air temperature decreases"
• "After 30 minutes of running, the heart rate increases by X"

For most tests, the simulation only needs to run for a very short time (around 100 ms of real time).

For long-running processes, such as disease dynamics over months or years, the simulation will need to run longer. According to the latest benchmarks, the current simulation speed is roughly 10 hours of simulated time per 1 minute of real time on an average laptop, which is good enough to make this kind of testing feasible.

That's it for now. In the next post, I'll dive deeper into the autonomic coordination system, which sits between the brain and the organs and is responsible for regulating almost everything in the body.