Develop Reference

Logger on multithread application causes exception because file is used by another procces c# [duplicate]

What is the best approach to creating a simple multithread safe logging class? Is something like this sufficient? How would I purge the log when it's initially created?
public class Logging
{
public Logging()
{
}
public void WriteToLog(string message)
{
object locker = new object();
lock(locker)
{
StreamWriter SW;
SW=File.AppendText("Data\\Log.txt");
SW.WriteLine(message);
SW.Close();
}
}
}
public partial class MainWindow : Window
{
public static MainWindow Instance { get; private set; }
public Logging Log { get; set; }
public MainWindow()
{
Instance = this;
Log = new Logging();
}
}

Here is a sample for a Log implemented with the Producer/Consumer pattern (with .Net 4) using a BlockingCollection. The interface is :
namespace Log
{
public interface ILogger
{
void WriteLine(string msg);
void WriteError(string errorMsg);
void WriteError(string errorObject, string errorAction, string errorMsg);
void WriteWarning(string errorObject, string errorAction, string errorMsg);
}
}
and the full class code is here :
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace Log
{
// Reentrant Logger written with Producer/Consumer pattern.
// It creates a thread that receives write commands through a Queue (a BlockingCollection).
// The user of this log has just to call Logger.WriteLine() and the log is transparently written asynchronously.
public class Logger : ILogger
{
BlockingCollection<Param> bc = new BlockingCollection<Param>();
// Constructor create the thread that wait for work on .GetConsumingEnumerable()
public Logger()
{
Task.Factory.StartNew(() =>
{
foreach (Param p in bc.GetConsumingEnumerable())
{
switch (p.Ltype)
{
case Log.Param.LogType.Info:
const string LINE_MSG = "[{0}] {1}";
Console.WriteLine(String.Format(LINE_MSG, LogTimeStamp(), p.Msg));
break;
case Log.Param.LogType.Warning:
const string WARNING_MSG = "[{3}] * Warning {0} (Action {1} on {2})";
Console.WriteLine(String.Format(WARNING_MSG, p.Msg, p.Action, p.Obj, LogTimeStamp()));
break;
case Log.Param.LogType.Error:
const string ERROR_MSG = "[{3}] *** Error {0} (Action {1} on {2})";
Console.WriteLine(String.Format(ERROR_MSG, p.Msg, p.Action, p.Obj, LogTimeStamp()));
break;
case Log.Param.LogType.SimpleError:
const string ERROR_MSG_SIMPLE = "[{0}] *** Error {1}";
Console.WriteLine(String.Format(ERROR_MSG_SIMPLE, LogTimeStamp(), p.Msg));
break;
default:
Console.WriteLine(String.Format(LINE_MSG, LogTimeStamp(), p.Msg));
break;
}
}
});
}
~Logger()
{
// Free the writing thread
bc.CompleteAdding();
}
// Just call this method to log something (it will return quickly because it just queue the work with bc.Add(p))
public void WriteLine(string msg)
{
Param p = new Param(Log.Param.LogType.Info, msg);
bc.Add(p);
}
public void WriteError(string errorMsg)
{
Param p = new Param(Log.Param.LogType.SimpleError, errorMsg);
bc.Add(p);
}
public void WriteError(string errorObject, string errorAction, string errorMsg)
{
Param p = new Param(Log.Param.LogType.Error, errorMsg, errorAction, errorObject);
bc.Add(p);
}
public void WriteWarning(string errorObject, string errorAction, string errorMsg)
{
Param p = new Param(Log.Param.LogType.Warning, errorMsg, errorAction, errorObject);
bc.Add(p);
}
string LogTimeStamp()
{
DateTime now = DateTime.Now;
return now.ToShortTimeString();
}
}
}
In this sample, the internal Param class used to pass information to the writing thread through the BlockingCollection is :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Log
{
internal class Param
{
internal enum LogType { Info, Warning, Error, SimpleError };
internal LogType Ltype { get; set; } // Type of log
internal string Msg { get; set; } // Message
internal string Action { get; set; } // Action when error or warning occurs (optional)
internal string Obj { get; set; } // Object that was processed whend error or warning occurs (optional)
internal Param()
{
Ltype = LogType.Info;
Msg = "";
}
internal Param(LogType logType, string logMsg)
{
Ltype = logType;
Msg = logMsg;
}
internal Param(LogType logType, string logMsg, string logAction, string logObj)
{
Ltype = logType;
Msg = logMsg;
Action = logAction;
Obj = logObj;
}
}
}

No, you're creating a new lock object every time the method is called. If you want to ensure that only one thread at a time can execute the code in that function, then move locker out of the function, either to an instance or a static member. If this class is instantiated every time an entry is to be written, then locker should probably be static.
public class Logging
{
public Logging()
{
}
private static readonly object locker = new object();
public void WriteToLog(string message)
{
lock(locker)
{
StreamWriter SW;
SW=File.AppendText("Data\\Log.txt");
SW.WriteLine(message);
SW.Close();
}
}
}

Creating a thread-safe logging implementation using a single monitor (lock) is unlikely to yield positive results. While you could do this correctly, and several answers have been posted showing how, it would have a dramatic negative effect on performance since each object doing logging would have to synchronize with every other object doing logging. Get more than one or two threads doing this at the same time and suddenly you may spend more time waiting than processing.
The other problem you run into with the single monitor approach is that you have no guarantee that threads will acquire the lock in the order they initially requested it. So, the log entries may essentially appear out of order. That can be frustrating if you're using this for trace logging.
Multi-threading is hard. Approaching it lightly will always lead to bugs.
One approach to this problem would be to implement the Producer/Consumer pattern, wherein callers to the logger only need to write to a memory buffer and return immediately rather than wait for the logger to write to disk, thus drastically reducing the performance penalty. The logging framework would, on a separate thread, consume the log data and persist it.

you need to declare the sync object at the class level:
public class Logging
{
private static readonly object locker = new object();
public Logging()
{
}
public void WriteToLog(string message)
{
lock(locker)
{
StreamWriter sw;
sw = File.AppendText("Data\\Log.txt");
sw.WriteLine(message);
sw.Close();
sw.Dispose();
}
}
}
Might be better to declare your logging class as static, and the locking object as #Adam Robinson suggested.

The question uses File.AppendText which is not an asynchronous method, and other answers correctly show that using a lock is the way to do it.
However, in many real-world cases, using an asynchronous method is preferred so the caller doesn't have to wait for this to get written. A lock isn't useful in that case as it blocks the thread and also async methods are not allowed inside the lock block.
In such situation, you could use Semaphores (SemaphoreSlim class in C#) to achieve the same thing, but with the bonus of being asynchronous and allowing asynchronous functions to be called inside the lock zone.
Here's a quick sample of using a SemaphoreSlim as an asynchronous lock:
// a semaphore as a private field in Logging class:
private static SemaphoreSlim semaphore = new SemaphoreSlim(1, 1);
// Inside WriteToLog method:
try
{
await semaphore.WaitAsync();
// Code to write log to file asynchronously
}
finally
{
semaphore.Release();
}
Please note that it's good practice to always use semaphores in try..finally blocks, so even if the code throws an exception, the semaphore gets released correctly.

SIgnalR- not use singleton pattern

In my application, I am sending real-time updates to each client based on his subscriptions.
So e.g. if a client is subscribed to items 1,2 & 3 he should only see updates from these items while at the same time if another client is subscribed to items 4,5 & 6 then he should be able to receive real-time updates for those items.
My problem is as soon as I connect with the second id SignalR forgets about the old group and starts notification of new ids only.
I guess it's because there's only one instance of real-time updates is running and it's being shared among all connected clients. Is there a way that each connected client has its own instance of a real-time object?
public class DataHub : Hub
{
private readonly RealTimeData data;
public DataHub() : this(RealTimeData.Instance) { }
public DataHub(RealTimeData rdata)
{
data = rdata; //can I instantiate RealTimeData object here?
}
public void Start(Int64 routerId)
{
data.StartTimer(routerId);
}
}
public class RealTimeData
{
private readonly static Lazy<RealTimeData> _instance = new Lazy<RealTimeData>(() => new RealTimeData(GlobalHost.ConnectionManager.GetHubContext<DataHub>().Clients)); //will avoiding this create a separate instance for each client?
private IHubConnectionContext Clients;
public Timer timer;
private readonly int updateInterval = 1000;
private readonly object updateRecievedDataLock = new object();
private bool updateReceivedData = false;
List<Items> allItems = new List<Items>();
private RealTimeData()
{
}
private RealTimeData(IHubConnectionContext clients)
{
Clients = clients;
}
public static RealTimeData Instance
{
get
{
return _instance.Value;
}
}
public void StartTimer(Int64 routerId)
{
this.routerId = routerId;
timer = new Timer(GetDataForAllItems, null, updateInterval, updateInterval);
}
public void GetDataForAllItems(object state)
{
if (updateReceivedData)
{
return;
}
lock (updateRecievedDataLock)
{
if (!updateReceivedData)
{
updateReceivedData = true;
//get data from database
allItems = Mapper.Instance.GetDataForAllItems(routerId);
updateReceivedData = false;
//send it to the browser for update
BroadcastData(allItems);
}
}
}
}

I think you are attacking the problem from a wrong angle. Instead of polling the DB each second let the action that saves to the DB publish a message on a message bus that you forward to the Clients.
Have a look at this library,
https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy
Demo project
https://github.com/AndersMalmgren/SignalR.EventAggregatorProxy/tree/master/SignalR.EventAggregatorProxy.Demo.MVC4
Disclaimer: I'm the author of the library

Group subscriptions in SignalR v2 are handled by using the this.Groups.Add and this.Groups.Remove methods in the Hub > HubBase ancestor class.
These methods could be used to subscribe to group 1,2,3 or 4,5,6 in your example by using something like this.
public class DataHub : Hub
{
public async Task Register(int groupNumber)
{
await this.Groups.Add(this.Context.ConnectionId, groupNumber.ToString());
}
public async Task Unregister(int groupNumber)
{
await this.Groups.Remove(this.Context.ConnectionId, groupNumber.ToString());
}
}
On the client this would be called by passing a group number to the Register/Unregister methods. An example might be:
this._DataHub.Invoke("Register", "1");
From you RealTimeData singleton or other business class that publishes the update, you would reference GlobalHost.ConnectionManager.GetHubContext<DataHub>() and call then use .Clients.Group("1").<clientMethod> to invoke the client-side method.
For example:
var hubContext = GlobalHost.ConnectionManager.GetHubContext<DataHub>();
hubContext.Clients.Group("1").UpdateDisplay("New tweet");
To read up a bit more of this have a look at http://www.asp.net/signalr/overview
I hope this answers the question.

How to Unit Test BackgroundWorker + PRISM InteractionRequest?

I have a reoccurring pattern in my WPF MVVM applications that has the following structure.
public class MyViewModel : NotificationObject
{
private readonly IService _DoSomethingService;
private bool _IsBusy;
public bool IsBusy
{
get { return _IsBusy; }
set
{
if (_IsBusy != value)
(
_IsBusy = value;
RaisePropertyChanged(() => IsBusy);
)
}
}
public ICommand DisplayInputDialogCommand { get; private set; }
public InteractionRequest<Notification> Error_InteractionRequest { get; private set; }
public InteractionRequest<Confirmation> GetInput_InteractionRequest { get; private set; }
// ctor
public MyViewModel(IService service)
{
_DoSomethingService = service;
DisplayInputDialogCommand = new DelegateCommand(DisplayInputDialog);
Error_InteractionRequest = new InteractionRequest<Notification>();
Input_InteractionRequest = new InteractionRequest<Confirmation>();
}
private void DisplayInputDialog()
{
Input_InteractionRequest.Raise(
new Confirmation() {
Title = "Please provide input...",
Content = new InputViewModel()
},
ProcessInput
);
}
private void ProcessInput(Confirmation context)
{
if (context.Confirmed)
{
IsBusy = true;
BackgroundWorker bg = new BackgroundWorker();
bg.DoWork += new DoWorkEventHandler(DoSomethingWorker_DoWork);
bg.RunWorkerCompleted += new RunWorkerCompletedEventHandler(DoSomethingWorker_RunWorkerCompleted);
bg.RunWorkerAsync();
}
}
private void DoSomethingWorker_DoWork(object sender, DoWorkEventArgs e)
{
_DoSomethingService.DoSomething();
}
private void DoSomethingWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
IsBusy = false;
if (e.Error != null)
{
Error_InteractionRequest.Raise(
new Confirmation() {
Title = "Error",
Content = e.Error.Message
}
);
}
}
}
Essentially, the pattern describes a dialog oriented workflow that allows the user to initiate (and provide input to) a long running operation without locking the UI. A concrete example of this pattern might be a "Save As..." operation where the user clicks a "Save As..." button, then keys in a text value for filename in a popup dialog, then clicks the dialog OK button, then watches a spin animation while their data is saved under the specified filename.
In the provided code example, initiating this workflow will perform the following operations.
Raise the Input_InteractionRequest Raised event to display a dialog in the UI for the purpose of collecting user input.
Invoke the ProcessInput callback (triggered when the user completes the dialog).
Check the Confirmed property of the InteractionRequest context to determine if the dialog was confirmed or canceled.
If confirmed...
Set the IsBusy flag.
Start a BackgroundWorker to perform the long running _DoSomethingService.DoSomething() operation.
Unset the IsBusy flag.
If an error occurred in DoSomething_DoWork, raise the Error_InteractionRequest Raised event to display a message box in the UI for the purpose of informing the user that the operation was not successful.
I would like to maximize unit testing coverage for this pattern, but I'm not quite sure how to approach it. I would like to avoid unit testing non-public members directly since the specific implementation of this pattern could change over time and in fact varies from instance to instance throughout my applications. I have considered the following options, but none of them seem appropriate.
Replace BackgroundWorker with IBackgroundWorker and inject it via ctor. Use a synchronous IBackgroundWorker during tests to ensure that unit tests do not complete before DoWork/RunWorkerCompleted methods are called. This would require a lot of refactoring and does not address testing the InteractionRequest callback either.
Use System.Threading.Thread.Sleep(int) to allow the BackgroundWorker operation to complete before the assertion stage. I don't like this because it is slow and I still don't know how to test code paths in the InteractionRequest callback.
Refactor the BackgroundWorker methods and InteractionRequest callback into Humble Objects that can be syncronously and independently tested. This seems promising, but structuring it has me stumped.
Unit test DoSomethingWorker_DoWork, DoSomethingWorker_RunWorkerCompleted, and ProcessInput synchronously and independently. This would give me the coverage I need, but I would be testing against a specific implementation rather than the public interface.
What is the best way to unit test and/or refactor the above pattern to provide maximum code coverage?

EDIT: See update below for simpler alternative (.NET 4.0+ only).
This pattern can be easily tested by abstracting the mechanics of BackgroundWorker behind an interface and then testing against that interface as described in this question. Once the quirks of the BackgroundWorker have been obscured behind an interface, testing the InteractionRequest becomes straightforward.
This is the interface I decided to use.
public interface IDelegateWorker
{
void Start<TInput, TResult>(Func<TInput, TResult> onStart, Action<TResult> onComplete, TInput parm);
}
This interface exposes a single Start method that accepts the following parameters.
Func<TInput, TResult> onStart - Comparable to BackgroundWorker.DoWork. This is where you would perform the primary work of your background operation. This delegate should accept a single parameter of type TInput and return a value of type TResult which should be passed on to the onComplete delegate.
Action<TResult> onComplete - Comparable to BackgroundWorker.RunWorkerCompleted. This delegate will be invoked after the onStart delegate completes. This is where you would perform any post-processing work. This delegate should accept a single parameter of type TResult.
TInput parm - The initial value to pass into the onStart delegate (or null if the onStart delegate does not require input). Comparable to passing an argument value to the Backgroundworker.RunWorkerAsync(object argument) method.
You can then use dependency injection to replace the BackgroundWorker instance with an instance of IDelegateWorker. For example, the rewritten MyViewModel now looks like this.
public class MyViewModel : NotificationObject
{
// Dependencies
private readonly IService _doSomethingService;
private readonly IDelegateWorker _delegateWorker; // new
private bool _IsBusy;
public bool IsBusy
{
get { return _IsBusy; }
set
{
if (_IsBusy != value)
{
_IsBusy = value;
RaisePropertyChanged(() => IsBusy);
}
}
}
public ICommand DisplayInputDialogCommand { get; private set; }
public InteractionRequest<Notification> ErrorDialogInteractionRequest { get; private set; }
public InteractionRequest<Confirmation> InputDialogInteractionRequest { get; private set; }
// ctor
public MyViewModel(IService service, IDelegateWorker delegateWorker /* new */)
{
_doSomethingService = service;
_delegateWorker = delegateWorker; // new
DisplayInputDialogCommand = new DelegateCommand(DisplayInputDialog);
ErrorDialogInteractionRequest = new InteractionRequest<Notification>();
InputDialogInteractionRequest = new InteractionRequest<Confirmation>();
}
private void DisplayInputDialog()
{
InputDialogInteractionRequest.Raise(
new Confirmation()
{
Title = "Please provide input...",
Content = new DialogContentViewModel()
},
ProcessInput
);
}
private void ProcessInput(Confirmation context)
{
if (context.Confirmed)
{
IsBusy = true;
// New - BackgroundWorker now abstracted behind IDelegateWorker interface.
_delegateWorker.Start<object, TaskResult<object>>(
ProcessInput_onStart,
ProcessInput_onComplete,
null
);
}
}
private TaskResult<object> ProcessInput_onStart(object parm)
{
TaskResult<object> result = new TaskResult<object>();
try
{
result.Result = _doSomethingService.DoSomething();
}
catch (Exception ex)
{
result.Error = ex;
}
return result;
}
private void ProcessInput_onComplete(TaskResult<object> tr)
{
IsBusy = false;
if (tr.Error != null)
{
ErrorDialogInteractionRequest.Raise(
new Confirmation()
{
Title = "Error",
Content = tr.Error.Message
}
);
}
}
// Helper Class
public class TaskResult<T>
{
public Exception Error;
public T Result;
}
}
This technique allows you to avoid the quirks of the BackgroundWorker class by injecting a syncronous (or mock) implementation of IDelegateWorker into MyViewModel when testing and an asyncronous implementation for production. For example, you could use this implementation when testing.
public class DelegateWorker : IDelegateWorker
{
public void Start<TInput, TResult>(Func<TInput, TResult> onStart, Action<TResult> onComplete, TInput parm)
{
TResult result = default(TResult);
if (onStart != null)
result = onStart(parm);
if (onComplete != null)
onComplete(result);
}
}
And you could use this implementation for production.
public class ASyncDelegateWorker : IDelegateWorker
{
public void Start<TInput, TResult>(Func<TInput, TResult> onStart, Action<TResult> onComplete, TInput parm)
{
BackgroundWorker bg = new BackgroundWorker();
bg.DoWork += (s, e) =>
{
if (onStart != null)
e.Result = onStart((TInput)e.Argument);
};
bg.RunWorkerCompleted += (s, e) =>
{
if (onComplete != null)
onComplete((TResult)e.Result);
};
bg.RunWorkerAsync(parm);
}
}
With this infrastructure in place, you should be able to test all aspects of your InteractionRequest as follows. Note that I am using MSTest and Moq and have achieved 100% coverage according to the Visual Studio Code Coverage tool although that number is somewhat suspect to me.
[TestClass()]
public class MyViewModelTest
{
[TestMethod()]
public void DisplayInputDialogCommand_OnExecute_ShowsDialog()
{
// Arrange
Mock<IService> mockService = new Mock<IService>();
Mock<IDelegateWorker> mockWorker = new Mock<IDelegateWorker>();
MyViewModel vm = new MyViewModel(mockService.Object, mockWorker.Object);
InteractionRequestTestHelper<Confirmation> irHelper
= new InteractionRequestTestHelper<Confirmation>(vm.InputDialogInteractionRequest);
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.IsTrue(irHelper.RequestRaised);
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecute_DialogHasCorrectTitle()
{
// Arrange
const string INPUT_DIALOG_TITLE = "Please provide input...";
Mock<IService> mockService = new Mock<IService>();
Mock<IDelegateWorker> mockWorker = new Mock<IDelegateWorker>();
MyViewModel vm = new MyViewModel(mockService.Object, mockWorker.Object);
InteractionRequestTestHelper<Confirmation> irHelper
= new InteractionRequestTestHelper<Confirmation>(vm.InputDialogInteractionRequest);
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.AreEqual(irHelper.Title, INPUT_DIALOG_TITLE);
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecute_SetsIsBusyWhenDialogConfirmed()
{
// Arrange
Mock<IService> mockService = new Mock<IService>();
Mock<IDelegateWorker> mockWorker = new Mock<IDelegateWorker>();
MyViewModel vm = new MyViewModel(mockService.Object, mockWorker.Object);
vm.InputDialogInteractionRequest.Raised += (s, e) =>
{
Confirmation context = e.Context as Confirmation;
context.Confirmed = true;
e.Callback();
};
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.IsTrue(vm.IsBusy);
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecute_CallsDoSomethingWhenDialogConfirmed()
{
// Arrange
Mock<IService> mockService = new Mock<IService>();
IDelegateWorker worker = new DelegateWorker();
MyViewModel vm = new MyViewModel(mockService.Object, worker);
vm.InputDialogInteractionRequest.Raised += (s, e) =>
{
Confirmation context = e.Context as Confirmation;
context.Confirmed = true;
e.Callback();
};
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
mockService.Verify(s => s.DoSomething(), Times.Once());
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecute_ClearsIsBusyWhenDone()
{
// Arrange
Mock<IService> mockService = new Mock<IService>();
IDelegateWorker worker = new DelegateWorker();
MyViewModel vm = new MyViewModel(mockService.Object, worker);
vm.InputDialogInteractionRequest.Raised += (s, e) =>
{
Confirmation context = e.Context as Confirmation;
context.Confirmed = true;
e.Callback();
};
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.IsFalse(vm.IsBusy);
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecuteThrowsError_ShowsErrorDialog()
{
// Arrange
Mock<IService> mockService = new Mock<IService>();
mockService.Setup(s => s.DoSomething()).Throws(new Exception());
DelegateWorker worker = new DelegateWorker();
MyViewModel vm = new MyViewModel(mockService.Object, worker);
vm.InputDialogInteractionRequest.Raised += (s, e) =>
{
Confirmation context = e.Context as Confirmation;
context.Confirmed = true;
e.Callback();
};
InteractionRequestTestHelper<Notification> irHelper
= new InteractionRequestTestHelper<Notification>(vm.ErrorDialogInteractionRequest);
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.IsTrue(irHelper.RequestRaised);
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecuteThrowsError_ShowsErrorDialogWithCorrectTitle()
{
// Arrange
const string ERROR_TITLE = "Error";
Mock<IService> mockService = new Mock<IService>();
mockService.Setup(s => s.DoSomething()).Throws(new Exception());
DelegateWorker worker = new DelegateWorker();
MyViewModel vm = new MyViewModel(mockService.Object, worker);
vm.InputDialogInteractionRequest.Raised += (s, e) =>
{
Confirmation context = e.Context as Confirmation;
context.Confirmed = true;
e.Callback();
};
InteractionRequestTestHelper<Notification> irHelper
= new InteractionRequestTestHelper<Notification>(vm.ErrorDialogInteractionRequest);
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.AreEqual(irHelper.Title, ERROR_TITLE);
}
[TestMethod()]
public void DisplayInputDialogCommand_OnExecuteThrowsError_ShowsErrorDialogWithCorrectErrorMessage()
{
// Arrange
const string ERROR_MESSAGE_TEXT = "do something failed";
Mock<IService> mockService = new Mock<IService>();
mockService.Setup(s => s.DoSomething()).Throws(new Exception(ERROR_MESSAGE_TEXT));
DelegateWorker worker = new DelegateWorker();
MyViewModel vm = new MyViewModel(mockService.Object, worker);
vm.InputDialogInteractionRequest.Raised += (s, e) =>
{
Confirmation context = e.Context as Confirmation;
context.Confirmed = true;
e.Callback();
};
InteractionRequestTestHelper<Notification> irHelper
= new InteractionRequestTestHelper<Notification>(vm.ErrorDialogInteractionRequest);
// Act
vm.DisplayInputDialogCommand.Execute(null);
// Assert
Assert.AreEqual((string)irHelper.Content, ERROR_MESSAGE_TEXT);
}
// Helper Class
public class InteractionRequestTestHelper<T> where T : Notification
{
public bool RequestRaised { get; private set; }
public string Title { get; private set; }
public object Content { get; private set; }
public InteractionRequestTestHelper(InteractionRequest<T> request)
{
request.Raised += new EventHandler<InteractionRequestedEventArgs>(
(s, e) =>
{
RequestRaised = true;
Title = e.Context.Title;
Content = e.Context.Content;
});
}
}
}
Notes:
Another option is to use the commercial version of the TypeMock isolation (mocking) framework. This framework is ideal for legacy code or code that is otherwise not well suited for unit testing. TypeMock allows you to mock just about anything. I will not go into the specifics of how this could be used for the question at hand, but it is still worth pointing out that it is a valid option.
In .NET 4.5 use of BackgroundWorker is deprecated in favor of the async/await pattern. The use of the IDelegateWorker (or some similar) interface as described above allows your entire project to migrate to the async/await pattern without the need to modify a single ViewModel.
Update:
After implementing the technique described above, I discovered a simpler approach for .NET 4.0 or better. To unit test an asynchronous process, you need some way to detect when that process is complete or you need to be able to run that process synchronously during tests.
Microsoft introduced the Task Parallel Library (TPL) in .NET 4.0. This library provides a rich set of tools for performing asynchronous operations that go far beyond the capabilities of the BackgroundWorker class. The best way to implement an asynchronous operation is to use the TPL and then return a Task from your method under test. Unit testing an asynchronous operation implemented in this way is then trivial.
[TestMethod]
public void RunATest()
{
// Assert.
var sut = new MyClass();
// Act.
sut.DoSomethingAsync().Wait();
// Assert.
Assert.IsTrue(sut.SomethingHappened);
}
If it is impossible or impractical to expose the task to your unit test, then the next best option is to override the way that tasks are scheduled. By default tasks are scheduled to run asynchronously on the ThreadPool. You can override this behavior by specifying a custom scheduler in code. For example, the following code will run a task using the UI thread.
Task.Factory.StartNew(
() => DoSomething(),
TaskScheduler.FromCurrentSynchronizationContext());
To implement this in a way that is unit testable, pass the task scheduler in using Dependency Injection. Your unit tests can then pass in a task scheduler that performs the operation synchronously on the current thread and your production application will pass in a task scheduler that runs the tasks asynchronously on the ThreadPool.
You can even go a step further and eliminate the dependency injection by overriding the default task scheduler using reflection. This makes your unit tests a little more brittle, but is less invasive to the actual code you are testing. For a great explanation on why this works, see this blog post.
// Configure the default task scheduler to use the current synchronization context.
Type taskSchedulerType = typeof(TaskScheduler);
FieldInfo defaultTaskSchedulerField = taskSchedulerType.GetField("s_defaultTaskScheduler", BindingFlags.SetField | BindingFlags.Static | BindingFlags.NonPublic);
defaultTaskSchedulerField.SetValue(null, TaskScheduler.FromCurrentSynchronizationContext());
Unfortunately, this will not work as expected from a unit test assembly. This is because unit tests, like Console applications, do not have a SynchronizationContext and you will get the following error message.
Error: System.InvalidOperationException: The current SynchronizationContext may not be used as a TaskScheduler.
To fix this you just need to set the SynchronizationContext in your test setup.
// Configure the current synchronization context to process work synchronously.
SynchronizationContext.SetSynchronizationContext(new SynchronizationContext());
This will get rid of the error, but some of your tests may still fail. This is because the default SynchronizationContext posts work asynchronously to the ThreadPool. To override this, simply subclass the default SynchronizationContext and override the Post method as follows.
public class TestSynchronizationContext : SynchronizationContext
{
public override void Post(SendOrPostCallback d, object state)
{
Send(d, state);
}
}
With this in place, your test setup should look like the code below and all of the Tasks in your code under test will run synchronously by default.
// Configure the current synchronization context to process work synchronously.
SynchronizationContext.SetSynchronizationContext(new TestSynchronizationContext());
// Configure the default task scheduler to use the current synchronization context.
Type taskSchedulerType = typeof(TaskScheduler);
FieldInfo defaultTaskSchedulerField = taskSchedulerType.GetField("s_defaultTaskScheduler", BindingFlags.SetField | BindingFlags.Static | BindingFlags.NonPublic);
defaultTaskSchedulerField.SetValue(null, TaskScheduler.FromCurrentSynchronizationContext());
Note that this does not prevent a Task from being started with a custom scheduler. In such a case, you would need to pass that custom scheduler in using Dependency Injection and then pass in a synchronous scheduler during tests.

Good Question. I will be trying your option 3 with some slight changes.
Make InteractionRequest testable, such that the test method can choose whether to confirm or cancel the operation. So this allows testing the individual paths. You can use IoC technique (inversion of control )
Refactor all logic in DoWork & RunWorkerCompleted to separate methods, this allows to test these methods independently (if required).
Then add a new flag IsAsyncFlag to indicate if this needs to be executed asynchronously or not. Turn off the Async mode when running the tests.
There is a lot of emphasize on the test coverage. But in my experience 100% test coverage is very difficult to achieve and it can never be a synonym to code quality. Hence my focus is in identifying & writing tests that would add value to the solution.
If you have found a better approach, please share.

WinRt C# null exception - object scope issue using IAsyncOperationWithProgress

I'm working in WinRt calling a WinRt Class Library from a Windows Store App using C# and SQLite... objects are returning null reference errors at unexpected times...
I'm trying to implement a logon service that checks to see if the current user is already logged in by checking if the data file exists, then checking if the user is the current user logged in...
The user can simply enter their ID and click a logon button. It creates a DataService object that wraps a SQLite database and is then "injected" into the UserStartupService.
The UserStartupService uses Dependency Injection, singleton and implements IDisposable.
Issue 1) if the user clicks the logon button a second time, the UserStartupService object constructor does not run and when internal objects are used they throw null reference errors even though it runs through the dispose method after it exits the using block, which forces me to deactivate the logon button, which is a kluge fix at best. A new user has to exit the program to log in as a new user. (The original code did not implement IAsyncOperationWithProgress, but that should not matter...)
Issue 2) I'm now trying to implement IAsyncOperationWithProgress to relay progress back to the UI and it gets a null reference error the instant it tries to use _dataFeedService on the line:
var json = await _dataFeedService.ValidateUser(userId);
Even though it runs the constructor at the top of the using statement as expected...
I think there is a scope/thread issue that I'm missing here. Maybe something obvious...
Any ideas? Thanks!
// logon button pressed...
private void LogOn_Click(object sender, RoutedEventArgs e)
{
// Create database service for DI
DataService _dataService = new DataService("MyData.sqlite");
// using statement for scope control
using (UserStartupService uss = UserStartupService.GetInstance(_dataService))
{
// progress bar...
CurrentProgress.Visibility = Windows.UI.Xaml.Visibility.Visible;
// create op and call...
IAsyncOperationWithProgress<string, int> op;
op = uss.SetUpUser(txtUserId.Text);
op.Progress = (info, progress) =>
{
CurrentProgress.Value = progress;
};
op.Completed = (info, status) =>
{
var results = info.GetResults();
// when completed...
if (status == AsyncStatus.Completed)
{
txtMessage.Text = "Current user data already loaded...";
CurrentProgress.Value = 100;
} // if cancelled...
else if (status == AsyncStatus.Canceled)
{
// Operation canceled - not implemented...
}
};
}
btnLogon.IsEnabled = false;
}
public sealed class UserStartupService : IDisposable
{
#region properties
// services
private static DataService _dataService;
private static DataFeedService _dataFeedService;
private static SqliteService _sqlMAFService;
private static SerialiseDeserialiseService _serializeService;
private string _token = String.Empty;
#endregion properties
#region constructors with DI and singleton pattern
// use this code to implement singleton patter...
// private constructor = can't instance without GetInstance...
private UserStartupService(DataService dataService)
{
// guard clause...
if (dataService == null)
{
throw new ArgumentNullException("DataService");
}
_dataService = dataService;
_dataFeedService = new DataFeedService();
_sqlMAFService = new SqliteService(_dataService);
_serializeService = new SerialiseDeserialiseService();
}
// implement singleton
public static UserStartupService GetInstance(DataService dataService)
{
_dataService = dataService;
return MyNestedSingletonClass.singleton;
}
class MyNestedSingletonClass
{
internal static readonly UserStartupService singleton = new UserStartupService(_dataService);
static MyNestedSingletonClass() { }
}
#endregion constructors with DI and singleton pattern
public IAsyncOperationWithProgress<string, int> SetUpUser(string userId)
{
return AsyncInfo.Run<string, int>((token, progress) =>
Task.Run<string>(async () =>
{
progress.Report(1);
try
{
// validate user against server REST feed and get token
var json = await _dataFeedService.ValidateUser(userId);
// ... it never gets here due to _dataFeedService null exception
// ...more code ... never gets here...
}
catch (Exception ex)
{
return ex.Message;
}
progress.Report(100);
return "";
}, token));
}
#region implement IDisposable
public void Dispose()
{
_serializeService = null;
_sqlMAFService.Dispose();
_sqlMAFService = null;
_dataFeedService.Dispose();
_dataFeedService = null;
_dataService.CloseConnection();
_dataService = null;
}
#endregion implement IDisposable
}

The using block will dispose uss before it is done executing, so that's where your null reference exceptions are coming from (for both issues).
If UserStartupService is a singleton, and it could be used multiple times, then don't dispose it.
Also, I would recommend using await rather than callbacks (it's usually simpler), so something like this should work:
private async void LogOn_Click(object sender, RoutedEventArgs e)
{
btnLogon.IsEnabled = false;
// Create database service for DI
DataService _dataService = new DataService("MyData.sqlite");
var uss = UserStartupService.GetInstance(_dataService);
// progress bar...
CurrentProgress.Visibility = Windows.UI.Xaml.Visibility.Visible;
// create op and call...
var op = uss.SetUpUser(txtUserId.Text)
.AsTask(progress => { CurrentProgress.Value = progress; });
var result = await op;
txtMessage.Text = "Current user data already loaded...";
CurrentProgress.Value = 100;
btnLogon.IsEnabled = true;
}

Calling a WCF method from a WPF client does nothing

I have a very simple WCF service running that has a single method that returns an enum based on the result of the method.
I have tested this WCF service through a very simple console app both locally and over the internet to my server and both work perfectly fine. However once I use the, literally exact, code in my WPF application calling the method does nothing. No exception, no timeout. Testing it locally with a breakpoint at the start of the WCF method I found it does not even reach that far when calling it from WPF.
Both service reference configurations that were generated in the app.config are identical between the console and WPF application.
Edit: Had hoped to not need to put as much code in here but I'll just dump the whole thing.
In WPF the code is being called from a button in a dialog. This button triggers an Coroutine call using Caliburn.Micro. The WCF call is then being called in the Execute method from the Coroutine.
public IEnumerator<IResult> SendReport()
{
var result = new Coroutines.SubmitNewExceptionIssueResult(Exception, UserNotes, Character);
yield return result;
if (result.Result == ErrorReportResult.OK)
TryClose();
else
// TODO
}
public class SubmitNewExceptionIssueResult : IResult
{
public event EventHandler<ResultCompletionEventArgs> Completed;
private ErrorReporterClient _client = new ErrorReporterClient();
private Exception _exception { get; set; }
private string _userNotes { get; set; }
private Character _character { get; set; }
public ErrorReportResult Result { get; private set; }
public SubmitNewExceptionIssueResult(Exception ex, string userNotes, Character character)
{
_exception = ex;
_userNotes = userNotes;
_character = character;
}
public void Execute(ActionExecutionContext context)
{
Result = _client.SendErrorReport(JsonConvert.SerializeObject(_exception, new JsonSerializerSettings
{
TypeNameHandling = TypeNameHandling.All
}),
_userNotes,
JsonConvert.SerializeObject(_character, new JsonSerializerSettings
{
TypeNameHandling = TypeNameHandling.All
}));
Completed(this, new ResultCompletionEventArgs());
}
}

The cause was indeed threading of some sort. While not happy with the implementation it now works.
Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.Normal, new System.Action(() => { /* send report code */ }));