Design patterns. And that book. I will not say anything more. I plan to do a whole series on Design Patterns. But this is a plan not a commitment. I will start out with the “Hello World” of design patterns: “Factory Pattern”. For the impatient, a Factory method pattern sample implementation in C++ is at… Read More »
When to use WPF Dependency Property vs INotifyPropertyChanged? A little background: WPF databinding has two essential parts: Source and Target. Now Target has to be a Dependency Property. But source can be a simple property with INotifyPropertyChanged implemented. Or a Dependency property. In both cases, any change to the property will see the UI getting… Read More »
How about checking if the method was called with right parameters as a part of your unit tests ? You can do it in many ways. Using FakeItEasy, it is easy to verify that the expected parameters were used to make the function call.
Recently while writing unit tests for a device driver I came across a situation. I had to simulate the call to the device to wait for sometime and then throw an error and then check if I handled it properly. This helped. This configures the Start method (which in real life issues command to the… Read More »
I often find myself dealing with protected methods in the unit testing land. Now if the method is public then this works
A.CallTo(() => fakeObject.MethodUnderTest()).MustHaveHappened();
However when the method is protected then it does not fly. With FakeItEasy you have to take the different approach. A.CallTo(fakeObject).Where(x => x.Method.Name ==”MethodUnderTest”).MustHaveHappened(); And needless to say, the method under test… Read More »