Isolation frameworks tend to lead to over-specified tests. I will try to eliminate dependencies before I mock them out. For example, replace my SQL storage provider with an in-memory one that has all the same semantics. This isn't a mock, but a fully functional (and independently tested) reusable component.
Although I will occasionally hand-roll a fake provider, generally when prototyping a website, I use Rhino.Mocks exclusively for my unit testing. I am concerned however by recent comments by Ayende that he is no longer doing active development on Rhino. I will definitely be exploring what Microsoft has added to VS11.
Moq is my first choice when creating Mocks and Stubs in .NET. If the initialization is too complicated (and unreadable) I'll hand roll my own, but this usually smacks of design problems or that your test scope is too great. Finally, I've had occasion to use Moles when working with legacy apps and apps that may have dependencies that are difficult to abstract out.
Isolation frameworks tend to lead to over-specified tests. I will try to eliminate dependencies before I mock them out. For example, replace my SQL storage provider with an in-memory one that has all the same semantics. This isn't a mock, but a fully functional (and independently tested) reusable component.
Although I will occasionally hand-roll a fake provider, generally when prototyping a website, I use Rhino.Mocks exclusively for my unit testing. I am concerned however by recent comments by Ayende that he is no longer doing active development on Rhino. I will definitely be exploring what Microsoft has added to VS11.
Moq is my first choice when creating Mocks and Stubs in .NET. If the initialization is too complicated (and unreadable) I'll hand roll my own, but this usually smacks of design problems or that your test scope is too great. Finally, I've had occasion to use Moles when working with legacy apps and apps that may have dependencies that are difficult to abstract out.