@natthapol-vanasrivilai I would suggest before you start with software development 101 you look up the developers background who you are trying to lecture here. @dc42 is also behind eschertech.com, which has a formal C++ verifier in its product portfolio. If you do more than a glancing view on the github repo, you see that the code is at times adjusted to allow for the verifier to run.
Formal verification may not be a common way to ensure software quality, but it's an approach that can cover a lot of issues that unit testing and integration testing cannot, or can only do at very high cost.
You should also consider that automotive control systems usually apply to systems that have a (mostly) fixed configuration, while RepRapFirmware does allow free-form reconfiguration of the system. I posit that no amount of unit and integration testing will be able to catch all errors in such a system. They also have hundreds of millions of monetary units in development budget which allows for large and cumbersome software development processes to be run.
As such, the release of beta and release candidate systems -- which by definition aren't supported deemed production ready releases are another way to gather more input about new changes, their performance, bugs, unintended side effects, etc. One of the reasons that 3.4 is still not in release is exactly that there are known issues that need to be analysed, the root cause found, fixed, tested, integrated, and released.
PS: I've seen "reasonably sized" software with unit tests and a code coverage quotient well beyond 90% in my 20+ years career in IT that simply didn't work in practice. So I completely disagree with you that the existence or absence of unit tests allows any guess about the quality of the software under test.