Re: Unit Tests. To say that they're not exhaustive is an extreme understatement. You test the happy-path, maybe a few sad-paths you can think up, and if you're a really fastidious unit-tester, then you add future sad-paths you discover (often post deployment) to your test scenarios. They cover the narrowest slice of the input domain and the assertions are against the narrowest slice of the output domain. They're _just barely_ better than nothing for establishing some correspondence between requirements and implementation.
One could graduate to property-based tests to attempt to do better than this by being able to specify a more global behavioral/constraint property that the implementation must uphold across all possible inputs. However, except in the case of really small state spaces, the input domain is still just a sampling of potential inputs (though perhaps many thousands rather than a small handful that would be represented by unit testing). You're probably 2-3 orders of magnitude closer to meaningfully establishing a correspondence between your requirements and your implementation this way, but purely by way of having created a kind of brute-force-ish automated generative unit testing system.
Re: The article posted. The final API exposed to the end-user is very simple and fairly idiomatic for interacting with registers (the approach could be applied to other kinds of resources as well). It's no more, and probably even less, baroque for such a task than a typical C API, but with much higher assurances provided to the consumer of the API. The compiler is more-or-less enforcing correct access to the underlying hardware model, so that you don't do something dangerous in any random corner of your program, like incorrectly write a value meant for one register to another, flub a mask, or misalign a shift. The article shows a way to get strong assurances with pretty much no extra effort on behalf of a consumer of `bounded-registers` because the crate authors baked the assurances into the crate via types.
How would you cover the domain of all possible combinations of register layouts, field layouts, field to register relationships and field values using unit testing and enforce those constraints from the bottom of the stack all the way to the top? How many unit tests would it be, and what assurances would you be able to claim, and how would you avoid the run-time cost of constantly checking and/or clamping values, and how could you compose those assurance claims with others further up the stack "by construction"?