Moq is a library that assists with running unit tests by providing easily mocked objects that implement interfaces and abstract classes. You can learn more about Moq on their website. There is a distribution for Silverlight, and in this post I’ll focus on some ways to use Moq for some more involved testing scenarios.
Download the source code for the example project
I started with the Simple Dialog Service in Silverlight and extended the example a bit. In the post, I promised that abstracting the dialog function behind an interface would facilitate unit testing. In this post, I’ll deliver on the promise.
Adhering to the pattern I described in Simplifying Asynchronous Calls in Silverlight using Action, I created the interface for a “Thesaurus” service. In this contrived example, we are showing a list of words. You can highlight a word and see the related synonyms in another list. You may also delete the words from the list.
Because we assume in the real word that there are thousands upon thousands of available words and synonyms, the view model won’t try to hold a complex object graph. I won’t have a special “word” entity that has a nested list of synonyms. Instead, I’ll maintain two lists: one of words, and one of the current synonyms. The service will be called when a word is selected to retrieve the list of synonyms for that word.
Enough set up … let’s take a refresher and look at the dialog service interface, along with the new thesaurus interface:
public interface IDialogService
{
void ShowDialog(string title, string message, bool allowCancel, Action<bool> response);
}
public interface IThesaurus
{
void GetSynonyms(string word, Action<List<string>> result);
void ListWords(Action<List<string>> result);
void Delete(string word);
}
As you can see, the interface is straightforward. In the sample project, I’ve implemented the dialog using the same code as my previous post (which involves a ChildWindow). The “implementation” of the thesaurus service actually only provides a few words and synonyms but is enough to run the application and see how it would function in the real world.
To run the actual “live” code, right-click on SimpleDialog.Web and choose “Set as startup project.” Then, right-click on SimpleDialogTestPage.aspx and choose “Set as start page.” Hit F5 and you’ll be in business. In this screenshot, I’ve selected a word that we run into quite often in the development world, and you can see that it has synonyms listed for it:
The view model is straightforward. It expects an implementation of the dialog service and the thesaurus service, then manages well on its own:
public class ViewModel : INotifyPropertyChanged
{
private readonly IThesaurus _thesaurus;
private readonly IDialogService _dialog;
public ViewModel()
{
Words = new ObservableCollection<string>();
Synonyms = new ObservableCollection<string>();
DeleteCommand = new DelegateCommand<object>( o=>ConfirmDelete(), o=>!string.IsNullOrEmpty(CurrentWord));
}
public ViewModel(IThesaurus thesaurus, IDialogService dialogService) : this()
{
_thesaurus = thesaurus;
_dialog = dialogService;
_thesaurus.ListWords(PutWords);
}
public DelegateCommand<object> DeleteCommand { get; set; }
public ObservableCollection<string> Words { get; set; }
public void PutWords(List<string> words)
{
Words.Clear();
foreach(string word in words)
{
Words.Add(word);
}
// default first word
if (Words.Count > 0)
{
CurrentWord = Words[0];
}
}
public ObservableCollection<string> Synonyms { get; set; }
public void PutSynonyms(List<string> synonyms)
{
Synonyms.Clear();
foreach (string synonym in synonyms)
{
Synonyms.Add(synonym);
}
}
public void ConfirmDelete()
{
_dialog.ShowDialog("Confirm Delete", string.Format("Do you really want to delete {0}?", CurrentWord),
true, b =>
{
if (b)
{
_thesaurus.Delete(CurrentWord);
_thesaurus.ListWords(PutWords);
}
});
}
private string _currentWord = string.Empty;
public string CurrentWord
{
get { return _currentWord; }
set
{
_currentWord = value;
_thesaurus.GetSynonyms(value, PutSynonyms);
OnPropertyChanged("CurrentWord");
DeleteCommand.RaiseCanExecuteChanged();
}
}
protected void OnPropertyChanged(string propertyName)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler != null)
{
handler(this, new PropertyChangedEventArgs(propertyName));
}
}
public event PropertyChangedEventHandler PropertyChanged;
}
Let’s walk through it briefly. The constructor initializes the lists and the delete command, which requires that there is a CurrentWord selected. When the services are passed in, it requests the list of words and asks the service to call PutWords with the list. This will load the results and set a default “current word” based on the first item in the list.
The current word is interesting, because when it is set, it goes out to request a list of synonyms. This is populated to the synonym list. When the view model is constructed and the list of words is received, it will automatically fire a request for the synonyms by setting the current word. The current word also updates the DeleteCommand so it can be enabled or disabled based on whether or not a word is currently selected.
The delete command itself calls the dialog service for confirmation, and only if the user confirms will it then call the service, delete the word, and then request a new list of words.
This view model is written so that I need almost zero code behind in my user control. The XAML looks like this, and is driven completely by data-binding:
<UserControl x_Class="SimpleDialog.MainPage"
xmlns_x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns_d="http://schemas.microsoft.com/expression/blend/2008" xmlns_mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns_cal="clr-namespace:Microsoft.Practices.Composite.Presentation.Commands;assembly=Microsoft.Practices.Composite.Presentation"
mc_Ignorable="d" d_DesignWidth="640" d_DesignHeight="480">
<Grid x_Name="LayoutRoot"
HorizontalAlignment="Center"
VerticalAlignment="Center">
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<ListBox
HorizontalAlignment="Center"
VerticalAlignment="Center"
ItemsSource="{Binding Words}"
SelectedItem="{Binding CurrentWord, Mode=TwoWay}"
SelectionMode="Single"
Grid.Row="0"
Grid.Column="0"/>
<ListBox
HorizontalAlignment="Center"
VerticalAlignment="Center"
Width="Auto"
ItemsSource="{Binding Synonyms}"
Grid.Row="0"
Grid.Column="1"/>
<Button
HorizontalAlignment="Center"
VerticalAlignment="Center"
Width="Auto"
Content="Delete"
Grid.Row="1"
Grid.Column="0"
cal:Click.Command="{Binding DeleteCommand}"/>
</Grid>
</UserControl>
The key here is the bindings from the delete button to the delete command, and the list box of words to the “current word.” This allows all of the other updates to cascade accordingly. I said I had “almost no” code behind. This is because I’m traveling light and decided not to drag an IoC container into the example. Therefore, in the code behind, I manually wire up the view model like this:
public MainPage()
{
InitializeComponent();
DataContext = new ViewModel(new Thesaurus(), new DialogService());
}
Now that we’ve set the stage, the real focus of this post is how to test what we’ve just created. I have a view model that does quite a bit, and want to make sure it is behaving. To make this happen, I’ll do two things. First, I’ll add the Silverlight Unit Testing Framework. I first discussed it in my post about unit testing views AND view models. Next, I’ll navigate to the Moq page and download the Silverlight bits (all of this is included in the reference project).
My test class is “view model tests.” The first thing I need to do is set up some support for the tests. We want a pretend list of words and synonyms, and mocks for the services the view model depends on. Our class starts out like this:
[TestClass]
public class ViewModelTests
{
private readonly List<string> _words = new List<string> {"test", "mock"};
private readonly List<string> _synonyms = new List<string> {"evaluation", "experiment"};
private readonly List<String> _mockSynonyms = new List<string> {"counterfeit", "ersatz", "pseudo", "substitute"};
private Mock<IDialogService> _dialogMock;
private Mock<IThesaurus> _thesaurusMock;
private ViewModel _target;
}
We created two words with synonym lists. The mocking of the services is as simple as declaring Mock<T>. There is more to it that we’ll cover, but this gets us started. I like to always have a reference to the object I am testing as target to make it clear what the test is run for.
Now we will need to set up the view model for all of our tests. Just like with the standard unit testing framework, we can flag a method as TestInitialize to do set up before each test is run. Take a look at my setup:
[TestInitialize]
public void InitializeTests()
{
_dialogMock = new Mock<IDialogService>();
_thesaurusMock = new Mock<IThesaurus>();
_thesaurusMock.Setup(
t => t.ListWords(It.IsAny<Action<List<string>>>()))
.Callback((Action<List<string>> action) => action(_words));
_thesaurusMock.Setup(
t => t.GetSynonyms(It.Is((string s) => s.Equals(_words[0])), It.IsAny<Action<List<string>>>()))
.Callback((string word, Action<List<string>> action) => action(_synonyms));
_thesaurusMock.Setup(
t => t.GetSynonyms(It.Is((string s) => s.Equals(_words[1])), It.IsAny<Action<List<string>>>()))
.Callback((string word, Action<List<string>> action) => action(_mockSynonyms));
_target = new ViewModel(_thesaurusMock.Object, _dialogMock.Object);
}
We create a new mock for every test so the internal counters are reset. Then, it gets a little interesting. The setup command allows you to determine what an expected call will be, and to provide results. Many methods return values, and there is a Result method to use for providing what those values should be. In our case, however, the methods do not return anything because they call the Action when complete. Therefore, we set up a callback so that we can perform an action when the method is fired.
To see how that works, take a look at the first set up. We are setting up our mock for the thesaurus service. The lambda expression indicates we expect the ListWords to be called, and the parameter can be any action that acts on a list of a strings. Now the important part: the callback. The callback has the same signature as the method. When the method is called, Moq will fire the callback and send the parameters. In our case, we take the action that was passed in, and call it with our list of words. This will mock the process of the view model requesting the word list, then having the PutWords method called with the actual list.
Next, we set up the GetSynonyms method twice. This is because we want to pass a different result based on the word that the method is called with. Instead of IsAny, we’ll use Is with a lambda that determines what will pass. In this way, we can compare specific values or even ranges. If the passed value is the first word, we call the action with the synonym list. If the passed value is the second word (“mock”), we call the action with the list of mocks. If any other value is passed in, we simply don’t care so we haven’t set that up.
The first test we’ll make is for setup. In other words, after the view model is constructed, we simply want to test that everything was set up appropriately. The view model promises to provide us with lists and commands, so we need to ensure these will be available when we bind to it.
[TestMethod]
public void TestConstructor()
{
// make sure it made the call
_thesaurusMock.Verify(t => t.ListWords(_target.PutWords), Times.Exactly(1),
"List words method was not called.");
_thesaurusMock.Verify(
t => t.GetSynonyms(It.Is((string s) => s.Equals(_words[0])), It.IsAny<Action<List<string>>>()),
Times.Exactly(1),
"Synonym method never called for first word.");
Assert.AreEqual(_target.CurrentWord, _words[0], "View model did not default target word.");
Assert.IsNotNull(_target.DeleteCommand, "Delete command was not initialized.");
Assert.IsTrue(_target.DeleteCommand.CanExecute(null),
"Delete command is disabled when selected word exists.");
CollectionAssert.AreEquivalent(_words, _target.Words, "Words do not match.");
CollectionAssert.AreEquivalent(_synonyms, _target.Synonyms, "Synonyms do not match.");
}
The setup commands “rigged” what we expect when a method is called. If these were the only actions we took, this would really be a “stub” (something there to make it happen) rather than a mock (something that changes and can be inspected after the test to determine the outcome). With Moq, we use verify to inspect the state of the mocked object. First, we verify that the word list was called exactly once. Next, we verify that the synonym list was called specifically with the first word. Next, we are comparing values, lists, and commands to make sure they are as we expect. For example, the view model should have already populated a list of synonyms that matches the first word, so we use the CollectionAssert to make sure the lists are equivalent.
Now we can do a little more in depth test. Let’s test selection. When we select the second word by setting the CurrentWord property, the view model should call the thesaurus service to retrieve the list of synonyms for ‘mock.’ The test looks like this:
[TestMethod]
public void TestSelection()
{
_target.CurrentWord = _words[1];
CollectionAssert.AreEquivalent(_mockSynonyms, _target.Synonyms, "Synonyms did not update.");
}
Technically, I could have verified the call as well and if you feel that is necessary, then by all means include that test. In this case, I know the synonym list simply won’t update itself, so if it ends up changing to the list I’m expected, I’m confident that the call took place. Therefore, I simply test that the mock synonyms were updated to the collection of synonyms on the view model.
What about a more complicated test? Our delete command requires confirmation, so the user doesn’t accidentally delete a word they did not intend to. Therefore, we need to set up the dialog service to return the results we want. We’ll have two tests: one that ensures the delete service is called when the user confirms, and another that ensures it is NOT called when the user cancels. The confirm test looks like this:
[TestMethod]
public void TestDeleteConfirm()
{
_thesaurusMock.Setup(t => t.Delete(It.IsAny<string>()));
_dialogMock.Setup(
d => d.ShowDialog(It.IsAny<string>(),
It.IsAny<string>(),
It.IsAny<bool>(),
It.IsAny<Action<bool>>()))
.Callback(
(string title, string message, bool cancel, Action<bool> action) => action(true));
_target.DeleteCommand.Execute(null);
_thesaurusMock.Verify(
t => t.Delete(It.Is((string s) => s.Equals(_words[0]))),
Times.Exactly(1),
"The delete method was not called on the service.");
}
First we set up the service to expect the delete call. Next, we set up the dialog. We don’t care about the parameters passed in. All we care about is that we call the action with “true” to simulate a user confirming the dialog. Once this is set up, we trigger the delete command, and verify that the delete service was called for the appropriate word.
For the cancel, we pass false in the action, and use Times.Never() on the method signature to ensure the delete service was not called.
Finally, because our delete command is only enabled when a current word is selected, we need to test that it is disabled with no words:
[TestMethod]
public void TestDeleteEnabled()
{
_target.CurrentWord = string.Empty;
Assert.IsFalse(
_target.DeleteCommand.CanExecute(null),
"Delete command did not disable with empty word selection.");
}
We already tested for the positive case in the constructor. Now, we simply clear the selection and confirm that the command is no longer allowed to execute.
If you ran the application earlier, you simply need to set the “test” project as the start-up project to run the unit tests. They will run directly in the browser.
As you can see, using the MVVM pattern appropriately ensures straightforward XAML (mostly binding-driven without cluttered code-behind) and very granular testing. Tools like Moq can make it much easier to test complicated scenarios by allowing you to easily set up dependencies, mock returns, and ultimately validate that the view model is behaving the way it is expected to.
Download the source code for the example project
Sales
or email us at sales@atmosera.com
Main Contacts
Headquarters & Beaverton Data Centers:
9705 SW Sunshine Court, Beaverton, OR 97005
Portland, OR: 1.503.222.2202
Toll-Free: 1.800.903.4852
Fax: 1.503.646.1400
Support
Support & Technical Assistance Command Center (TACC) Hours: 24x7x365
Access Web Help Desk: WHD Login
Contact Support: Email Support
Legacy Services Support
EasyStreet Technical Support Site
Legacy Infinity Internet Technical Support Site
Billing
PO Box 2518, Portland, OR 97208
Contact Billing: Email Accounting
Stay Connected
Newsletter, news flash, events, maintenance notices, and email preferences.