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.
Strict mocking vs Loose mocking is a question something which comes up often when various mocking frameworks like Moq, NSubstitute, Rhino Mocks, FakeItEasy are compared. So what is it? Suppose you create a fake of a class and do not configure the behavior of one of its method or property. Strict mocking: If the test… Read More »
There are many situations where you want to partially mock the class. You typically want to change the behavior of a single method in a class having many methods. So what you do is partial mocking. FakeItEasy and Partial Mocking go very well together.
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… Read More »