Hm. I think, one could condense the argumentation as follows: Number of Unit tests = c * (Complexity * Use Cases + State-Tests) for some constant c, if Complexity is a measure of the interface complexity, use cases is the number of use cases of the API and state-tests is the number of tests required due to statefulness of the API.
I think, this approximation is at least not wrong. I don't know if the characterization is complete, but it looks right enough to fool me :)
However, I think the problem in the argumentation is that the author assumes that "use cases" is small. While I agree, that usually, the number of use cases for an API should be small, there certainly are abstractions with a lot of use cases which are good even though they require a lot of unit tests.
An example of such a big abstraction is something I developed in the recent university project. Basically, it is a domain specific language which is compiled into state machines on partial bit sequences (which are used to describe data deserializers). The major job of this abstraction can be described in a few formulas and the abstraction hides enough complexity to be worth it, but it requires quite a large number of unit tests due to the number of possible edge cases in the specification of the DSL. Thus, at least I'd consider it a good abstraction in spite of needing many unit tests.
I think, this approximation is at least not wrong. I don't know if the characterization is complete, but it looks right enough to fool me :)
However, I think the problem in the argumentation is that the author assumes that "use cases" is small. While I agree, that usually, the number of use cases for an API should be small, there certainly are abstractions with a lot of use cases which are good even though they require a lot of unit tests.
An example of such a big abstraction is something I developed in the recent university project. Basically, it is a domain specific language which is compiled into state machines on partial bit sequences (which are used to describe data deserializers). The major job of this abstraction can be described in a few formulas and the abstraction hides enough complexity to be worth it, but it requires quite a large number of unit tests due to the number of possible edge cases in the specification of the DSL. Thus, at least I'd consider it a good abstraction in spite of needing many unit tests.