How to test my business layer?

I have been using Moq and initially Rhino Mocks over the last year together with TDD. I have really e开发者_Go百科njoyed developing in this way however I have come to a point in my project where I feel maybe this is not what I need to be doing.

I have tested and drove out my design and all works fine. Now I have a layer above my objects where I need to test. Since I have a number of objects (using Inversion of Control via interfaces), stubbing and mocking all these services seems like so much work. In one test, I have to stub out at least 8 services before I can even test my code. It just seems like writing lots of code which has no real benefit and is so laborious.

My question is "Is there a better way to do this"? Is this where behaviour driven design or some other methodology would be better suited as I am not really doing unit testing?

Only on a rare occasion, you would have a class depending on 8 other classes.

In my experience, only ModelView in MVVM could have such massive dependency. If in your business logic you have a class having dependency on more than 4 other services, I believe you need to refactor your code.

Idea is the principle of single responsibility, you will have more classes but less code in them.

If you need 8 services then you will need 8 stubs/mocks. I don't think you can avoid this.

If you want to code less, then you may want to refactor your unit-test too and create a hierarchy or some other suitable OO commodity for group all the 8 services' setup code.

EDIT

Otherways, you could create a "megaobject". Let' suppose the 8 services implement each a different interface: IService1, IService2 and so on. In the unit test, you can create an interface that groups each service's interface:

interface ISuperInterface: IService1, IService2, ... { }

Then you just need to mock one object.

BDD at a unit level is more about the mindset and vocabulary than anything else. If I think about your class without using the word "test", just concentrating on its responsibilities and behaviour, it helps me to work out what might be wrong. I think if your class needs 8 services to do its job, perhaps it has too many responsibilities. Could you delegate some of those responsibilities to another class, then mock that?

BDD at a scenario level is really intended to help you think about the behaviour, scope and responsibilities of whole systems, and have conversations around them. I don't think it will help you to resolve the design of the class you're talking about. However, with my BDD hat on I can tell you that BDD isn't about testing. It's about discovering ignorance, addressing it, then passing on that knowledge to make the code easy and safe to change.

So I advise doing whatever makes the code easy and safe to change. If you're writing brittle tests which are going to break the first time someone changes something then, yes, maybe take it up a level (to scenarios and system behaviour) instead. Otherwise write some nicer unit-level examples and refactor the code as @Aliostad suggests.