In my current project we’re using Moq as our mocking framework for unit testing. It’s a very nice package – very simple, very intuitive for someone who has his wrapped around basic mocking concepts, but tonight I ran into an annoying limitation that, while rare, impeded my tests considerably. Consider the following code: 1: public interface IOut 2: { 3: void DoOut ( out string outval); 4: } 5: 6: [Test] 7: public void TestMethod() 8: { 9: var mock = new Mock<IOut>(); 10: string outVal = "...
When we're working Reflection, we tend to think in different terms than we do when we're actually calling methods. There's an extra level of abstraction in everything we do. Translating between these levels of abstraction isn't always easy or intuitive, so I'll try to go over some common paths, using this following class definition for my examples: using System.Reflection; public delegate void MyDelegate (); public class MyClass { public void MyMethod() { } private void MyPrivateMethod() { } public...