DDD - ApplciationServices Unit test

After reading Uncle Bob blog and TSS id DEAD article, I wanted to code some more tests.

My application is using layers : ApplicationService -> Model -> Support.

The application service defines the use cases. It's a bit procedural code (loadX, call X.doSomething, saveX). In some cases, the appService class needs lots of external dependencies.

For example, I have an object "D" used at the end of a "workflow". So when working with it, I need to check some rules on the objects "A" / "B" / "C" linked to this one. Say we have 3 entities related, each one with its own repository and in very special use case I need to check another rule deeper (like "AA" == another repository).

My appService will have something like 8 to 10 dependencies (5 repositories + some business services inter-entities). testing that isnot my "forte". I lack courage when mocking too muche services. If each service has 3 methods but my appService only need one, then I need to know which method to mock or mock/stub all the methods (and mocking/stubbing 2/3 of useless methods).

There's a lot of problems I think. My first one is too much dependencies. I just don't want to split the dependencies and hide them under the carpet. Surely the domain entities are perhaps problematics too : bad boundaries, too much separation, etc.

Ater reading an article (uncle bob), I was thinkg : I'm doing it wrong. perhaps the appService will need to express / declare an interface with WHAT it needs. But how do name it ? how to split it ? I'm not sure it's a good idea to put no related services together. Write something like a facade and tests will become easier (I now know that my class is coupled to theses externals services and I know exactly which ones).

• How do you test your appServices ? (unit or integration test only ?)
• Do you think splitting the injected services ("facade" like or something more business or something else) is a good approach ?

thanks