Estamos planeando usar async / await en nuestros modelos de vista MVVM, pero tenemos un problema grave al probar la unidad este código. Al usar NUnit y un simulacro escrito a mano para nuestros mensajes, estamos perdiendo la corrienteSynchronizationContext.

Se muestra mejor con el siguiente código de ejemplo de reproducción pequeña:

[Test] public void TestMethod()
{       
  Func<Task> asyncMethod = async () =>
    {
      var context = SynchronizationContext.Current;
      await TaskEx.Yield();
      Assert.AreEqual(context, SynchronizationContext.Current);
    };

    // Establish the new context
    var syncCtx = new SingleThreadSynchronizationContext(false);
    SynchronizationContext.SetSynchronizationContext(syncCtx);

    // Invoke the function and alert the context to when it completes
    var t = asyncMethod();
    t.ContinueWith(delegate { syncCtx.Complete(); }, TaskScheduler.Default);

    // Pump continuations and propagate any exceptions
    syncCtx.RunOnCurrentThread();
    t.GetAwaiter().GetResult();
}

En realidad, la mayor parte de este código se roba de la implementación de AsyncPump de Stephen Touben su blog.

Interesante todo lo necesario para hacer este pase de prueba es tirar en unExecutionContext.SuppressFlow(); Antes de llamar al método asíncrono. Esto podría ser suficiente para solucionar nuestro problema, pero no sé lo suficiente acerca de ExecutionContext y quiero un entendimiento más profundo de lo que está pasando.

¿Por qué el código generado por la instrucción await traga el SynchronizationContext actual?
¿Hay otra forma obvia de usar un contexto de un solo hilo para la prueba unitaria del código async / await?

PS: estamos usando .Net4 y Microsoft.CompilerServices.AsyncTargetingPack.Net4

PPS: esto también ocurre en un proyecto simple utilizando el estable Microsoft.Bcl.Async en lugar del ATP