mocking / interaction / expect breaks encapsulation to perform "testing".
Thus it is often a test of the implementation's assumptions when first written, and even worse, when the code is maintained/edited, the test is merely changed to get it to pass, because unit tests with mocks are usually:
1) fragile to implementation
2) opaque as to intent
Whereas input/output integration points are more reliable, transparent, and less fragile to implementation changes if the interface is maintained.
However, if you must do mock-level interaction testing, Spock has made it almost palatable in Javaland.
This is one area where functional fans get to make the imperative folks eat their lunch.
If you actually know what the halting problem is, you know that if your code triggers that, it is pretty much broken. If you're not writing a programming language.
I'd guess the complexity is dependent on the decision graph complexity: cyclic vs acyclic, entrance/exit points...
If it gets to conditional / puzzle evaluation that starts to get Turing Complete, then it will hit the halting problem, which I believe is thought to be noncomputable for nontrivial graphs / code.
Maybe they didn't want to be RedHat? As in, all those projects are open-source and if Google invested in them, they'd be investing in something they can't fully control. Google's goal is to make money, not fight for user freedom, after all.
Thus it is often a test of the implementation's assumptions when first written, and even worse, when the code is maintained/edited, the test is merely changed to get it to pass, because unit tests with mocks are usually:
1) fragile to implementation 2) opaque as to intent
Whereas input/output integration points are more reliable, transparent, and less fragile to implementation changes if the interface is maintained.
However, if you must do mock-level interaction testing, Spock has made it almost palatable in Javaland.
This is one area where functional fans get to make the imperative folks eat their lunch.