One of the causes of a hard-to-test code listed by Gerard Meszaros in his book "xUnit Test Patterns" is highly coupled code. From the point of view of Pythoscope the problem is not so much on preparing objects for testing (because that's automated), but on readability of test cases generated for those problematic pieces of code. There are three main properties of objects that affect readability of their setup code, listed below.
Number of dependencies (Construction Blob)
That's the number of other objects the constructor requires. As the list of parameters gets bigger, readability drops significantly. We can work around this problem by adding creation methods to generated test classes.
Depth of dependencies (Onion Parameter)
If a constructor parameter requires other objects to be created, which in turn require other objects, and so on, we have a case of a deep dependency structure. One way of breaking this deep dependency structure is cutting it at the first level by introducting a test double.
Number of calls on those dependencies
Even if the object itself is easy to construct number of calls that are being made on it may be very problematic. Test doubles tend to get less readable as the number of calls increase, in which case we may be better off by using the original object. Keep in mind that there are cases (mostly related to side effects) we don't have a choice than to use a mock, so some kind heuristic will be needed to keep tests readable despite those constraints.
The combination of deep dependencies with long lists of calls to them are especially hard to keep readable. A viable solution may be not to cut the dependencies with mock on the first level, but on the level with the least number of calls.