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

Rx Request Response Throttle

My most recent project at work was to introduce a Request Response messaging API into one our systems, as previously we were receiving a daily batch file with upwards of 4m entries when we only needed around 500-1,000 of them.

One of the restrictions was that we had to have mechanisms in place to ensure we did not flood the Service API with 1,000’s of messages all in one go, as this would cause delays for all other systems using the same API, as this was a widely used and critical service.

We had to make sure we do not have more than 4 requests queued at any one time (the API had 4 worker processes) so that everyone gets their fair share of the service. This made a great exercise for Rx 😀

The system could be represented via this diagram 

2015-03-07 13_47_38-RxRequestResponse-OverviewOne of my favourite things that Rx brought to the table, was this concept of virtual time using schedulers which you can learn about in Lee Campbells – Intro to Rx free on-line book under Part 4 – Testing Rx.

I started with an initial controller, which subscribes to an injected IObservable<Request> and calls the service straight away for each request. Responses are handled similarly, the controller subscribes to an IObservable<Response> on the IApiService using the injected IObserver<Response>

public class RequestResponseController
{
    public RequestResponseController(IRequester requester, IResponseHandler responseHandler, 
        IApiService service, ISchedulers schedulers)
    {
        requester
            .ObserveOn(schedulers.ThreadPool)
            .Subscribe(request => service.SendRequest(request));
            
        service.Responses
            .ObserveOn(schedulers.ThreadPool)
            .Subscribe(responseHandler);
    }
}

With a simple test to prove this

[Test]
public void Should_get_respponse_when_request_received()
{
    _requests.OnNext(new Request(1));
    
    _schedulers.ThreadPool.AdvanceBy(1); // Send Request
    _requestsReceived.Should().HaveCount(1);
    
    _serviceScheduler.AdvanceBy(1); // Process Request
    
    _schedulers.ThreadPool.AdvanceBy(1); // Process Response
    _responsesProcessed.Should().HaveCount(1);
}

Which passed with the following output:

Advancing ThreadPool by 1
Received Request: 1
  
Advancing ServiceScheduler by 1
Sending Response: 1
   
Advancing ThreadPool by 1
Processed Response: 1

I then went on to publish 5 requests from the requester, of which only 4 should be sent to the service before receiving a response.

[Test]
public void Should_send_max_4_requests_at_one_time()
{
    // Schedule 5 requests
    _requests.OnNext(new Request(1));
    _requests.OnNext(new Request(2));
    _requests.OnNext(new Request(3));
    _requests.OnNext(new Request(4));
    _requests.OnNext(new Request(5));
    
    _schedulers.ThreadPool.AdvanceBy(5); // Attempt to send all 5 requests
    _requestsReceived.Should().HaveCount(4); // Check if only 4 requests received by service
}

 This test failed as expected, and gave the following results:

Advancing ThreadPool by 5
Received Request: 1
Received Request: 2
Received Request: 3
Received Request: 4
Received Request: 5
Expected collection to contain 4 item(s), but found 5.

 In order to achieve the throttling, I added a new Subject

  field which acts as a throttle to the requester, so that only 4 requests are active at any time.

private readonly Subject _throttle = new Subject();

This could be achieve by using the  IObservable.Zip() extension, which brings 2 sequences together, and publishes at the rate of the slowest sequence. I also immediately published 4 objects into the  _throttle sequence so that the first 4 requests would immediately fire.

public RequestResponseController(...)
{
    // Service Subscription stayed the same
 
    requester
        .ObserveOn(schedulers.ThreadPool)
        .Zip(_throttle,(request, i) => request) // <---------Added Zip
        .Subscribe(request => service.SendRequest(request));
 
    for (int i = 0; i < 4; i++) // Init _throttle with 4 requests
        _throttle.OnNext(i);
}

 This made the test pass, and could be represented by the following marble diagram: 

Throttle  |1234----------------------------
Requester |----1-2-3-4-5-------------------
Result    |----1-2-3-4---------------------

 The missing piece of the puzzle was to ensure that queued requests would be sent out as soon as a response comes back. This could be represented by the following test:

[Test]
public void Should_send__5th_queued_request_after_receiving_1st_response()
{
    // Schedule 5 requests
    _requests.OnNext(new Request(1));
    _requests.OnNext(new Request(2));
    _requests.OnNext(new Request(3));
    _requests.OnNext(new Request(4));
    _requests.OnNext(new Request(5));
    _requests.OnNext(new Request(6));
 
    _schedulers.ThreadPool.AdvanceBy(5); // Attempt to send all 5 requests
 
    _serviceScheduler.AdvanceBy(1);
    _requestsReceived.Should().HaveCount(5); // Check that 5th request received by service
}

 Which failed and gave the following output:

Advancing ThreadPool by 5
Received Request: 1
Received Request: 2
Received Request: 3
Received Request: 4
 
Advancing ServiceScheduler by 1
Sending Response: 1
Expected collection to contain 5 item(s), but found 4.

 The implementation for this was easy, just subscribe to the  IApiService.Response  sequence, with an Action that pushes a value onto the _throttle sequence.

public RequestResponseController(...)
{
    service.Responses
        .Subscribe(r => _throttle.OnNext(0));
        
    // Rest of the Constructor
}

 And could be represented by the following marble diagram:

Throttle  |1234--------------0--0--0--0--0--0--0-
Requester |----1-2-3-4-5-6-7----------------89---
Result    |----1-2-3-4-------5--6--7--------89---
Response  |------------------1--2--3--4--5--6--7-

Stay tuned as I will be blogging about the Time-out -> Retry implementation for this controller soon. Where if we don't receive a response within 30 seconds, we retry, and to handle multiple responses for the same request (e.g. due to the retry) so that we do not process duplicate responses.

As always the code can be found on GitHub @ michal-ciechan/codePerf/20150308-RxRequestResponse/

 

 

.NET Nested Loops vs Hash Lookups

Recently I was tasked with improving the performance for a number of processes we have at work as some of these processes where taking as long as 25 mins to complete. After some initial investigation I noticed all 3 processes suffered from the same issue… Nested Loops. Basically the slow running code could be represented by the following:  

foreach (var a in _listA)
{
    foreach (var b in _listB)
    {
        if (a.String1 == b.String1) continue;
        // Do some work
    }
}

As you can hopefully spot straight away, this code would take O(N2) time for which means the time taken to complete the outer loop exponentially grows as the 2 collections of items got bigger, which can be seen in the graph below. In my tests, when both collections where at 100k, it took almost 9 minutes to complete with a single string comparison. 2015-03-02 03_45_20-Book1 - ExcelWhen you see such code, you straight away should see the low hanging fruit of where time could be shaved off in that loop, which is by removing the inner foreach by using a Hashed collection class such as the HashSet/Dictionary/Lookup to create an Index of the properties of interest.so that foreach element in A, you don’t have to iterate over each element in B. You first create an Index for the property you will be looking up, and then for each element in A, you calculate the hash for the required property and check if the hash exists in your Index (may also need to do direct comparisons in case of hash collisions). Therefore you only iterate once over List B in order to generate the Index, and once over List A in order to check if the property exists in your index, therefore taking O(n) time (linear).

 
// Could be HashSet or Dictionary or any other Hashbased collection 
var lookup = _listB.ToLookup(b => b.String1);
 
foreach (var a in _listA) 
{ 
    if (lookup.Contains(a.String1)) 
        continue; 
    // Do some work 
} 

Implementing this in my tests, made the A[100k], B[100k] test case go from 8min to 250ms which is what allowed me to make the process run in matter of seconds compared to 25 minutes!

AlgorithmA[1k] , B[1k]A[100k] , B[10k]A[10k] , B[100k]A[100k] , B[100k]
Nested Loop500ms50s50s500s
Hash Lookup0.058ms50ms125ms256ms

As you can see, using a Hash Lookup takes exponentially more time than a Nested Loop. It is also worth noting that it is quicker to build a lookup for the smaller collection and iterate over the larger collection as can be seen by the highlighted values in the table above. This is actually a topic which I will be blogging about in the near future! A few things to be aware of are:

  • Immutable Keys – A fundamental assumption by most if not all hashed collections (yet to see an implementation with handlers to some sort of HashCodeChanged event) is that the HashCode/key must not change. As if it changed, it will no longer be detected by the collection as it will be looking up the object using the new HashCode and not finding it, as it would still be in the bucket for the old HashCode. Again, this is a topic I will probably blog about in the near future.
  • Hash Algorithm – Make sure there is a performant hash algorithm being if you have rolled your own.
  • Hash Collisions – It is usual for 2 separate properties to map to a single hash, therefore you need to ensure Equals() is overloaded in the custom key struct/class or provide a custom Equality comparer.
  • Hash the Smaller Collection – If you have a choice of which collection to build an Index for, it is generally better to build it for the smaller collection. I will be blogging about this in the near future!

You can find all the source code on GitHub @ michal-ciechan/codePerf/20150302-NestedLoopsVsHashLookups