This post is really just tying together some ideas. A year ago I posted on my preference for classicist TDD. However, when it comes to services you are dealing only with behavior not state so using classicist approaches becomes trickier. One way out of this issue is to test the results of the service on the stateful objects (entities, repositories) that the service interacts with. Having experimented with that style the outcome is usually unsatisfactory because the service's tests frequently mirror the tests against the stateful objects themselves. That leads to un-needed code (or worse duplicated code) in the tests, and multiple tests failing when you get something wrong.

So I think this is one of those cases where it is clear that the way to test the System Under Test (SUT - the service you are testing in this case) is by its interaction with its depended upon components (DoC).

I also think that this approach helps prevent the obesity issues with Fat Controllers and Flabby Services because it discourages you from adding much additional behavior to your service beyond command and control logic, because it is then hard to test that outcomes of that logic.

So in the context of services I would vote for looking at 'mocking' as an approach.

For controllers, we have found auto-mocking containers to be a powerful way to get our code under test.