TDD – Mock.Throw Interface Call Verification Technique

First of all I did not know what to call this post, so it is what it is. If you have any better suggestions leave a comment!

Often I find myself writing a class which ties multiple classes together. I like to call these controllers. Therefore using a MVVMC (Model-View-ViewModel-Controller) pattern which is a combination of MVVM and MVC as I believe they suit each other very well.

One problem that bugs when I am doing this using a TDD approach is that my interface call verification methods fail because of either NotImplementedException or NullReferenceException because as I test the first interface call, the rest is not yet implemented, or the mocks return null.

Rant

For the TDD purists out there, no I do not write a non compilable test first. I develop using the following cycle:

  1. Think about what I need and how I would test it
  2. Create an empty class to represent what I need
  3. Create an empty method
  4. Add comments of what this method should do
  5. Change the comments to empty implementations (often another method which throws new NotImplementedException)
  6. Write a test for the first fake implementation
  7. Code the implementation
  8. Repeat 6-7 until no empty implementations left.
  9. Repeat steps 1-8 for each interface I used.

I guess you can call it Test Driven Design, rather than Development. Maybe one day it will change, who knows, but currently that is how I enjoy coding the most, makes me most productive as well as churn out decent quality code. I guess that is an idea for another blog post 😀

Rant Over

The Technique

[Test]
[ExpectedException(typeof(MockCalled))]
public void ProcessData_CallsWorker()
{
    var list = new List {1};
 
    // Setup worker
    _worker.Setup(w => w.DoWork(list))
           .Throws(); // Technique
 
    // Act
    _controller.ProcessData(list);
}

 The Reason

The reason for adding throws is to stop the flow of the program as soon as it hits that mock. I often use this when I want to verify a call was made to a mock, and I don’t want to test the remaining logic or flow of the class under test.

 

Method Under Test

 

The above logic can be represented by the following code:

internal void ProcessData(List data)
{
    var newData = _worker.DoWork(data);
 
    if (newData.Count == 0)
        throw new NotImplementedException(); // Do Something else
 
    SaveData(newData);
}

Having such a method, my first test would be to make sure my worker gets called. The conventional way of testing this would be something along these lines (I am using Moq, but most Mocking frameworks are similar)

[Test]
public void ProcessData_CallsWorker()
{
    var list = new List {1};
 
    // Setup worker
    _worker.Setup(w => w.DoWork(list))
        .Verifiable();
 
    // Act
    _controller.ProcessData(list);
 
    _worker.VerifyAll();
}

But using this method, the code blows up with a NullReferenceException.

NullReference

Yes you could make the worker.DoWork(list) return a list but that would just make the test throw an NotImplementedException as neither of the other paths are implemented yet.

A better option is to make the mocked worker.DoWork(list) throw an exception:

_worker.Setup(w => w.DoWork(list))
    .Throws(new MockCalled());

You then let the MockCalled exception bubble up the call stack, and get handled by you inside your test:

try
{
    _controller.ProcessData(list); // Will throw when calls worker
}
catch (MockCalled)
{
}

You should throw a custom exception ( I have used MockCalled : Exception ) so that you know for a fact that when you receive a MockCalled exception, it could of only come from your mocked method.

If your testing framework allows for annotating a test with ExpectedType (NUnit and MSTest do, haven’t tried any others), then this becomes even cleaner:

[Test]
[ExpectedException(typeof(MockCalled))]
public void ProcessData_CallsWorker()
{
    var list = new List {1};
 
    // Setup worker
    _worker.Setup(w => w.DoWork(list))
        .Throws();
 
    // Act
    _controller.ProcessData(list);
}

In the above method, I wrapped the Throws(new MockCalled()) in an extension method .Throws()  for Moq as below:

public static void Throws(this ISetup mock)
    where TMock : class
{
    mock.Throws(new MockCalled());
}

 Or you could go even further and wrap the Setup call as well:

public static ISetup ThrowsOn(this Mock mock, Expression> expression) 
    where T : class
{
    return mock.Setup(expression).Throws();
}

 Giving you a slightly neater interface:

[Test]
[ExpectedException(typeof(MockCalled))]
public void ProcessData_CallsWorker()
{
    var list = new List {1};
 
    // Setup worker
    _worker.ThrowsOn(w => w.DoWork(list));
 
    // Act
    _controller.ProcessData(list);
}

 Other Usages

Imagine the following scenario

Same Class Usage

This represents a scenario where you want to test that another method on the class under test was called. The usual way of testing something like this would be to mark your ProcessData() method as public virtual, and then Mock the class under test verifying  that the ProcessData method was called.

public virtual List ProcessData(List data) { ... }
 
[Test]
public void Iteration_HasData_CallsProcessData()
{
    // Setup repo
    var list = new List {1};
    _repo.Setup(r => r.GetData()).Returns(list);
 
    _mock.Setup(x => x.ProcessData(list))
        .Verifiable();
 
    // Act
    _mock.Object.Iteration();
 
    // Assert
    _mock.VerifyAll();
}

There are 2 issues with that:

  1. You have to make the ProcessData method public virtual so that Moq can provide an implementation that registers the call.
  2. DataChanged logic will throw a NullReferenceException if it depends on the result of ProcessData, so you have to return a valid result from ProcessData.

The first point has never sat well with me, so this is where you can again use this technique.

The second point, well thats a pain each time, so rather than setting up a verifiable virtual implementation for ProcessData that return valid data for the method to progress gracefully why not make it throw the MockCalled exception?

[Test]
[ExpectedException(typeof(MockCalled))]
public void Iteration_HasData_CallsProcessDataThrow()
{
    // Setup repo
    var list = new List {1};
    _repo.Setup(r => r.GetData()).Returns(list);
    // Setup mock
    _mock.ThrowsOn(x => x.ProcessData(list));
        
    // Act
    _mock.Object.Iteration();
}

 This makes the test a bit cleaner, but there is still a flaw which does not sit well with me. That you have to mark the method as public virtual. This is probably something that I could take a look at and implement in Moq, but I will leave that for another day. At the moment what I have been doing which is working quite well, is making the first logical interface interaction throw the exception.

In the scenario above, the first call which happens right at the start of ProcessData is the IWorker.DoWork(), so I can make this method throw the exception, knowing that it should get to there gracefully at which point the exception will be thrown.

This allows the method to stay private or internal, and does not need to be virtual.

[Test]
[ExpectedException(typeof(MockCalled))]
public void Iteration_HasData_CallsProcessDataWhichCallsWorker()
{
    // Setup repo
    var list = new List {1};
    _repo.Setup(r => r.GetData()).Returns(list);
    // Setup Worker
    _worker.ThrowsOn(x => x.DoWork(list));
        
    // Act
    _controller.Iteration();
}

As always you can find the code @ GitHub on codePerf/20150319-TddMockThrowInterfaceCallVerificationTechnique

WPF – MVVM Animated Dialogs

Recently someone asked what is a good way to show animated dialog boxes/controls while keeping the views and view models separated in an MVVM fashion.

My answer was to use data templates! Such that, you have a view model to represent a dialog box/control (I will refer to these as simply dialogs), whether it be an alert, modal view to edit properties, informational or anything else, and let the view decide how and where to show it by using a common service to which you can pass these alerts in.

Data templates allowed me to get an affect like this:

AnimatedDialogs

The view model layer could be represented using the following dependency graph:

IDIalogService

The IDialogService exposes 1 method (ShowDialog) which is used by the view model in order to show any IDialog, with an optional generic continuation Action<TDialog> so some more logic can be carried out after the dialog closes. The IDialogService also exposes 2 events (DialogShown / DialogClosed) which allow any interested parties to carry out some action whenever a dialog is shown or closed. This is used by the MainViewModel, which hosts the CurrentDialog property, in order to show and hide dialogs.

public interface IDialogService
{
    IContinueWith ShowDialog(TDialog dialog) where TDialog : IDialog;

    event EventHandler DialogShown;
    event EventHandler DialogClosed;
}

The MainViewModel which is used as the DataContext for the MainWindow, looks like the following:

public class MainViewModel : ViewModelBase
{
    public MainViewModel(IDialogService dialogService) { ... }
    public RelayCommand CommandAboutMe { ... }
    public IDialog CurrentDialog { ... }
    public ObservableCollection Posts { ... }
}

The MainViewModel, has the IDialogService injected into it, and it subscribes to the IDialogService.DialogShown and IDialogService.DialogClosed events, which in turn set the CurrentDialog to a given IDialog (on shown) or null (on closed). This allows the external sources to show and hide dialogs on the MainWindow via the IDialogService.

MainWindow.xaml:

<Window x:Class="MvvmAnimatedDialogs.MainWindow" ... >
    <Grid>
        <DockPanel>
             /* Content of window */
        </DockPanel>
        <ContentControl Content="{Binding CurrentDialog}" />
    </Grid>
</Window>

In the MainWindow, the DockPanel contains all of the UI layout for the main window, and the ContentControl is a place-holder for the dialogs, which is bound the the MainViewModel.CurrentDialog. It uses the power of WPF data templates in order to decide how to display whatever IDialog object it is bound to (via the CurrentDialog property) and will display nothing if it is null. It is important to either make the ContentControl the last element, or set its Z-Index to a value higher than any other Z-Index, in order for the dialogs to be shown on top of everything else.

The ContentControl will traverse up the tree, trying to find data templates for an object of the current type that its Content property is bound to, so the data templates are placed as a ResourceDictionary in the App.xaml file.

<Application x:Class="MvvmAnimatedDialogs.App" ....
             xmlns:viewModel="clr-namespace:MvvmAnimatedDialogs.ViewModel">
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Dialogs/DialogTemplates.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>
</Application>

And inside the DialogTemplates.xaml, I have DataTemplates for each concrete implementation of IDialog.

DialogTemplates.xaml

<ResourceDictionary>
    <DataTemplate DataType="{x:Type dialogs:SimpleDialog}" Resources="{StaticResource DialogResources}">
        <Border>            
            <Border>                
                <Grid Margin="20">
                    <DockPanel Grid.Column="1">
                        <StackPanel DockPanel.Dock="Bottom" Orientation="Horizontal" HorizontalAlignment="Right">
                            <Button Content="OK" Command="{Binding CommandOk}" />
                        </StackPanel>
                        <TextBlock Text="{Binding Message}" />
                    </DockPanel>
                </Grid>
            </Border>
        </Border>
    </DataTemplate>
    <DataTemplate DataType="{x:Type dialogs:OkCancelDialog}" Resources="{StaticResource DialogResources}">
        <Border>
            <Border>
                <Grid Margin="20">
                    <DockPanel Grid.Column="1">
                        <StackPanel DockPanel.Dock="Bottom" Orientation="Horizontal" HorizontalAlignment="Right">
                            <Button Content="OK" Command="{Binding CommandOk}" />
                            <Button Content="Cancel" Command="{Binding CommandCancel}" />
                        </StackPanel>
                        <TextBlock Text="{Binding Message}" />
                    </DockPanel>
                </Grid>
            </Border>
        </Border>
    </DataTemplate>
</ResourceDictionary>

Yes I know the plumbing code for each dialog should be abstracted into its own UserControl/CustomControl but for this exercise copy + paste will have to suffice.

As usual, you can find all the code on GitHub @ codePerf/20150315-WpfMvvmAnimatedDialogs