Ola the 'flow!
I have been using Moq recently in my development process and I like what I am able to achieve.
However, I find myself making my methods (and properties for the mostpart) virtual so that I can replace them with a mock in my tests.
Other than "you are making all your methods and properties overrideable", what real world ramifications are there to this course of action?
Thanks for your time,
Dan
I don't think there are any serious ramifications. The chances of accidentally overriding a method/property that you didn't intend to are pretty slim.
I think that the ability to substitute one class of object for another (e.g. a mock object) is a good thing, and to do that you need a base class with virtual methods/properties. It reminds me of using abstract base classes to adhere to the Open Closed Principle.
Well, you prevent most kinds of optimizations. First, the JITter may not know which implementation is going to be called, (And he can't, since you may be using a Mock, right?) So, all these property accessors, that would have been inlined will be real calls now. Thx to inlining, simple properties will not add real overhead at runtime. Virtual properties won't be inlined, so they do.
That was the performance side of things, the other problem is, that you can't trust properties to work as you think they are working. Every property could be overridden. Even by yourself, because "this one time it really made sense, right?". So you'll find yourself checking the call tree more often than usual to check which implementations are applicable to the code you are working on.