# MVVM + TPL + Unit tests

DevFeed: [MVVM + TPL + Unit tests](<https://devfeed.tech/articles/mvvm-tpl-unit-tests-38407.md>)

Original publisher: [Read original article](<https://khmylov.com/2011/09/mvvm-tpl-unit-tests/>)

Author: Andrew Khmylov

Published: 2011-09-27T00:00:00Z

Content type: tutorial

Language: en

Sources: [Despite the odds](<https://devfeed.tech/sources/despite-the-odds.md>)

Topics: [MVVM](<https://devfeed.tech/topics/mvvm.md>), [unit tests](<https://devfeed.tech/topics/unit-tests.md>), [async](<https://devfeed.tech/topics/async.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [Web](<https://devfeed.tech/topics/web.md>), [WPF](<https://devfeed.tech/topics/wpf.md>)

Tags: [async](<https://devfeed.tech/tags/async.md>), [asynchronous](<https://devfeed.tech/tags/asynchronous.md>), [callback](<https://devfeed.tech/tags/callback.md>), [mvvm](<https://devfeed.tech/tags/mvvm.md>), [tdd](<https://devfeed.tech/tags/tdd.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

The article discusses testing MVVM view-model commands that use the Task Parallel Library for asynchronous operations. It critiques static task creation for making dependencies difficult to mock and presents an ICommand wrapper that signals completion, allowing tests to synchronize with the asynchronous task.

## Source excerpt

UPD: This implementation didn't work as well as expected, please read the follow-up article. Recently I've faced an issue with writing unit tests for view model commands that use Task Parallel Library for asynchronous operations. Searching over the web was not really helpful, so I spent some time designing the approach to handle such cases. The most common way to start tasks with TPL is by using one of the static Task.Factory.StartNew(...) methods. If you are mockist TDD guy, this should already raise an alert in your head. Static members are not test-friendly and do not allow you to inject mock dependencies into your module. One may say that using tasks is just an implementation details and should not be concerned when testing the behavior. I would agree if we were speaking about a regular async method that allows you to perform some action when its execution completes (in a form of callback or event, doesn't really matter). That simply doesn't work for me because the asynchrony is used inside the command handler, so there is no way to specify the continuation outside of the view model. My first (and probably the bad one) idea was to create a service for running the tasks. Then it would be easy to mock it and run tasks synchronously. Hopefully, I rejected this solution - creating another dependency just didn't sound right. I decided to create a special ICommand implementation instead that would notify me when the execution completes. This should do the trick because you can always use the thread sync primitives in the test environment to wait on the asynchronous task. For simplicity's sake I just created the wrapper around RelayCommand from MVVM Light Toolkit (you could use your favorite library or implement the command from scratch yourself). public class AsyncDelegateCommand: ICommand { private readonly RelayCommand _innerCommand; public event EventHandler ExecuteCompleted; public event EventHandler CanExecuteChanged { add { _innerCommand.CanExecuteChanged += value