The mocking framework in question is purely for testing purposes. i.e. it enables you to use mock objects in your tests so that your test is not cluttered with all the goo (as Stephen puts it) around setting up your dependencies.
You use a mock when it is a dependency of the thing that you are testing. How you achieve this is by coding against an Interface rather than against an implementation, which as it happens is excellent practice to get into, since it enables you to then test your objects in isolation, and it means that you can develop your client application against the interface exposed by your service layer without caring a hoot about the implementation of that service layer. i.e. your client is developed independently to the service layer. Personally, I tend to follow the following model: Ui Repository ServiceLayer This really removes all dependencies upon the service layer from the client. The Ui developer creates the ui, and specifies the interface that it is working against. The repository developer services the ui developer by implementing the interface that s/he defined. Meanwhile the data guys are busy working away on the service layer. They might or might not have released an interface library for the repository devloper to use. When the service layer is exposed via an interface, the repository developer can set about translating from the data structures of the service interfaces to those of the Repository interfaces. Also, if you are using an IoC container, swapping your development repository for your build repository should be as simple as. -- You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhinomocks?hl=en.
