Обычно я решаю подобные проблемы, заключая глобальное состояние в абстрактный класс или интерфейс, который можно создавать и удалять.Затем вместо прямого доступа к глобальному состоянию я внедряю экземпляр моего абстрактного класса или интерфейса в код, который его использует.
Это позволяет мне смоделировать глобальное поведение и делает так, чтобы мои тесты независеть или проявлять это несвязанное поведение.
Вот один из способов, которым вы могли бы сделать это.
public interface IContext
{
void Post(SendOrPostCallback d, Object state);
}
public class SynchronizationContextAdapter : IContext
{
private SynchronizationContext _context;
public SynchronizationContextAdapter(SynchronizationContext context)
{
_context = context;
}
public virtual void Post(SendOrPostCallback d, Object state)
{
_context.Post(d, state);
}
}
public class SomeClass
{
public SomeClass(IContext context)
{
_context = context;
}
void _tracker_IndexChanged(object sender, IndexTrackerChangedEventArgs e)
{
_context.Post(o => _view.SetTrackbarValue(_tracker.Index), null);
}
// ...
}
Тогда вы можете высмеять или заглушить IContext
, чтобы вам не пришлось беспокоиться омногопоточность, и может использовать простую реализацию, которая просто выполняет делегат.
Если бы я написал модульные тесты, чтобы смоделировать это, я бы также написал «интеграционные» тесты более высокого уровня, которые не делали это, нобыло меньше гранулярных проверок.