Here is the scenario, I have a method that takes an object, however - nowhere in your CUT (class under test) can you publicly access this object to verify state the state of it. I run into this scenario a lot regarding view models, the view model exposes things that we need to look at and interact with as public properties but anything the user doesn’t interact with or see is private which can make testing a pain. Let’s look at an example of something we can easily test before we get to the problem.
[TestMethod]
public void SaveCommandGetsSetWhenConstructed()
{
//Arrange
var adapterMock = new Mock<INewOrderAdapter>();
adapterMock.Setup(x => x.DeclinedBuyItNowPartNumbers)
.Returns(new List<string>() { "12345" });
var vm = new PartDeclinedViewModel(eventAggregator, adapterMock.Object)
{
SelectedLineItems = new ObservableCollection<DeclineReasons>()
{
DeclineReasons.CONDITION
},
CommentsText = "Testing",
SelectedPartNumber = "12345"
};
//Act (done when the constructor is initialized)
//Assert
Assert.IsNotNull(vm.SaveCommand);
}
So - you have defined SaveCommand in your view model, it’s a public delegate command, I can easily write a test that verifies that I am setting the method when we call the constructor for our class. Look at the test below – it does just that,(there are a few things in the arrange portion of the test that are telling me my view model needs a little refactoring but ignore that for now).
Now that we have looked at that example, what if the method that the delegate command we are using for the SaveCommand calls something that changes a private property? Whatever it is isn’t visible to the user so we don’t have anything that is publicly accessible in the view model. We don’t need it. Except we want to test that our method does the right thing to this private object. We can use a callback to set a value to a variable that is scoped inside the test method and then call our asserts on the state of the object. Let me try to use some more examples.
When we create the view model in the test above you can see that a mock adapter is created. This mock adapter has methods we need to mock out using Mock.Setup(), this of course means we can make them do whatever we want them too. So instead of having adapter.Save(myType, myObject) do whatever it normally does (we aren’t testing that here). We can mock it to say “Take the variable that was passed in and put it in this local variable” – that is what the callback does. See the test below which does just that.
[TestMethod]
public void LineItemIdGetsSetIfExists()
{
//arrange
DeclinedPart declinedPart = new DeclinedPart();
var lineItem = new LineItem() {PartNumber = "12345", LineItemId = 555};
var currentSaleOrder = new CreateSalesOrder();
currentSaleOrder.LineItems = new List<CreateLineItem>() { (CreateLineItem)lineItem };
var adapterMock = new Mock<INewOrderAdapter>();
adapterMock.Setup(x => x.DeclinedBuyItNowPartNumbers)
.Returns(new List<string>() {"12345"});
adapterMock.Setup(x => x.CurrentSalesOrder).Returns(currentSaleOrder);
adapterMock.Setup(x => x.SaveDeclineReason(It.IsAny<DeclinedPart>())).
Callback((DeclinedPart x) => declinedPart = x);
var vm = new PartDeclinedViewModel(eventAggregator, adapterMock.Object)
{
SelectedLineItems = new ObservableCollection<DeclineReasons>()
{
DeclineReasons.CONDITION
},
CommentsText = "Testing",
SelectedPartNumber = "12345"
};
//Act
vm.SaveCommand.Execute();
//Assert
Assert.AreEqual(declinedPart.LineItemId, lineItem.LineItemId);
}
There you have it, now you look at the local variable (the one you created in your test method) and check that your method does what you wanted it to. People will point out that you can use things like private accessors for this task however I tend to shy away from those. They don't always seem to be reliable and they tend to make the tests more confusing - in my opinion of course. at any rate - this is just another nifty little trick for examining the state of something you don't necessarily have direct access to.
Comments
Post a Comment