Я ищу альтернативу Microsoft Fakes в .NET Core. Я знаю, что это больше не поддерживается в .NET Core. Я просто не понимаю, почему нет, я считаю, что это было хорошее решение в определенных ситуациях.
Моя проблема в том, что я хочу издеваться над DateTime.Now. Раньше это можно было сделать с помощью следующего кода:
System.Fakes.ShimDateTime.NowGet = () =>
{
return new DateTime(2000, 1, 1);
};
Это описано в документации Microsoft, см. Ссылку для получения дополнительной информации: https://docs.microsoft.com/en-us/visualstudio/test/using-shims-to-isolate-your-application-from-other-assemblies-for-unit-testing?view=vs-2017
На данный момент я решил это, создав оболочку для DateTime, которая выглядит так:
/// <summary>
/// Used for getting DateTime.Now(), time is changeable for unit testing
/// </summary>
public static class SystemTime
{
/// <summary>
/// Normally this is a pass-through to DateTime.Now, but it can be
/// overridden with SetDateTime( .. ) for testing or debugging.
/// </summary>
public static Func<DateTime> Now = () => DateTime.Now;
/// <summary>
/// Set time to return when SystemTime.Now() is called.
/// </summary>
public static void SetDateTime(DateTime dateTimeNow)
{
Now = () => dateTimeNow;
}
/// <summary>
/// Resets SystemTime.Now() to return DateTime.Now.
/// </summary>
public static void ResetDateTime()
{
Now = () => DateTime.Now;
}
}
Этим решением я обязан следующему сообщению на StackOverflow: Модульное тестирование: DateTime.Now
Но я пока не удовлетворен этим решением, потому что чувствую, что должен скорректировать свою реализацию для моего тестирования. Я не думаю, что это желательно.
Надеюсь, кто-нибудь сможет мне с этим помочь, заранее спасибо за усилия.
DateTime.Now
(или эквивалента, если это другая система, платформа и т. Д.), Чтобы вы могли внедрить его. Скрытые зависимости - бич тестирования, потому что ... ну ... они скрыты, т.е. они не видны вам, поэтому их слишком легко пропустить и не заметить при настройке новых сценариев тестирования. Чтобы вы фактически поместили ее за абстракцию, которую затем нужно внедрить (что вы также должны сделать), делает эту зависимость видимой и, следовательно, более простой в обращении. - person Lasse V. Karlsen   schedule 25.09.2018static
, я бы (как и Лассе) обычно реализовал это какDateTimeProvider : IDateTimeProvider
. Тогда ваши классы имеют явную зависимость отIDateTimeProvider
. Это делает кристально ясным, какие классы зависят отDateTime
, и, следовательно, над ними нужно высмеивать. Обратной стороной использованияstatic
с точки зрения модульного тестирования является то, что ваши тесты не могут быть распараллелены (поскольку существует только одно значениеstatic
, поэтому, если разные тесты хотят моделировать разные значения, они будут давить друг на друга). - person mjwills   schedule 25.09.2018