I get where you're going with this. You are talking about macro phenomena of multitudes of simple axioms interacting with each other. Let me put it this way:

I get where you're going with this. You are talking about macro phenomena of multitudes of simple axioms interacting with each other. Let me put it this way: Given an exact set of tax laws, network standards or traffic rules I can implement this perfectly and easily with types, intuition and programming methodology alone. (Another hint: don't use mutable variables or even better forego variables and go point free; it eliminates a whole class of bugs that has to do with state.) Implementing a specification is trivial even when the specification is complex. It's simply a mapping from english to programming logic. There is little complexity here. I think what you're getting at is a sort of derivation of the specification from a macro goal. For example, what is the best way to tax society so that society has maximal benefit and zero loop holes for bad actors? What is the best way to create a set of traffic rules and network standards so that throughput is maximized, fair among everyone, and (most importantly) 100% bug free? This is hard and specs derived from a macro goal can be bad or wrong. This also usually happens before programming begins. Bad specs are not something that unit tests are really used for. Unit tests are used for logic errors. To catch where a programmer implemented a spec incorrectly. While I can see some logical value for using unit tests to test for macro level goals this stuff in practice happens at the IO level and is the domain of integration tests. You are not testing a "unit" when measuring a macro level goal, the philosophy of an integration test applies in this case because a macro level goal is basically operating at the integration level rather than the unit level.