Sebastian Scholz

Yeah, we have some unit tests.

And for smaller functionalities, we do use those to test.

The theme that we have in our code is we have one big project, but it's built up in smaller crates.

So the big onboard data handling system software uses a lot of smaller crates that we also develop.

And the smaller crates, they have unit tests for their functionality.

But for the big on-board data handling system, it's harder to test these things because they're very much hardware specific.

So, for example, if I want to test that our persistence works, so we are able to store data in some sort of flash memory, I can't just write a unit test for it because I need the actual hardware.

Sure, I could try to emulate it somehow.

But that's a bunch of extra work and I'm not guaranteed that it is going to actually work on the hardware itself.

So in an embedded environment, you kind of can't avoid doing integration tests because you need to test on the hardware.

So you're just going to test the whole system as a whole.

Yeah.

So in fact, all of our flash memory, first of all, it's a very specific chip usually that has some built-in error detection and correction.

So on a hardware level, we are protected against it.

But on top of that, for specific parts of code that is stored on this flash, because

That's the important thing.

Code needs to be stored somewhere.

And so if that code gets corrupted, you're going to be in big trouble.

So one of the steps that we do in our bootloaders is that we check this code for errors.

For example, for bit flips.