Изоляция тестируемого кода с помощью Microsoft Fakes

Изоляция кода — это стратегия тестирования, часто реализованная с помощью таких средств, как Microsoft Fakes, где тестируемый код отделен от остальной части приложения. Это разделение достигается путем замены частей приложения, взаимодействующих с кодом в тестируемом коде с заглушками или заглушками. Это небольшие фрагменты кода, контролируемые тестами, которые имитируют поведение фактических частей, которые они заменяют.

Преимуществом этого подхода является то, что он позволяет сосредоточиться на тестировании конкретных функциональных возможностей кода в изоляции. Если тест завершается ошибкой, вы знаете, что причина находится в изолированном коде, а не в другом месте. Кроме того, использование заглушки и заглушки, предоставляемые Microsoft Fakes, позволяет протестировать код, даже если другие части приложения еще не работают.

Requirements

• Visual Studio Enterprise
• Проект .NET Framework
• Поддержка проектов в стиле пакета SDK, .NET Core и .NET 5.0, представленная в Visual Studio 2019 (обновление 6), включена по умолчанию в обновлении 8. Дополнительные сведения см. в статье Microsoft Fakes для проектов .NET Core и проектов в стиле SDK.

Примечание.

Профилирование с помощью Visual Studio недоступно для тестов, использующих Microsoft Fakes.

Роль Microsoft Fakes в изоляции кода

Microsoft Fakes играет ключевую роль в изоляции кода, предоставляя два механизма — заглушки и заглушки.

• Заглушки: они используются для замены класса небольшой заменой, реализующей тот же интерфейс. Это требует, чтобы приложение было разработано таким образом, чтобы каждый компонент зависел только от интерфейсов, а не от других компонентов.

• Шимы: они используются для изменения скомпилированного кода приложения во время выполнения. Вместо вызова указанного метода приложение запускает код схима, который предоставляет тест. Коды могут заменить вызовы сборок, которые нельзя изменить, например сборки .NET.

Как правило, заглушки используются для вызовов в решении Visual Studio, а также для вызовов других ссылочных сборок. Это связано с тем, что в вашем решении рекомендуется разделить компоненты, определив интерфейсы таким образом, что требуется привязывание. Однако внешние сборки часто не имеют отдельных определений интерфейса, поэтому вместо этого используются оболочки.

Рекомендации на время использования заглушки

Заглушки обычно используются для вызовов в решении Visual Studio, так как рекомендуется отделять компоненты путем определения интерфейсов таким образом, что требуется привязывание. Однако внешние сборки, такие как System.dll, обычно не предоставляются с отдельными определениями интерфейса, поэтому в этих случаях будут использоваться шимы.

Использование заглушки включает в себя проектирование приложения таким образом, чтобы различные компоненты не зависели друг от друга, а только от определений интерфейса. Это разъединение делает приложение более надежным и гибким, и позволяет подключать компонент, тестируемый для заглушки реализаций интерфейсов для тестирования.

На практике можно создать типы заглушки из определений интерфейса в Visual Studio, а затем заменить реальный компонент заглушкой в тесте.

Рекомендации на "Когда следует использовать шимы"

Хотя заглушки используются для вызовов в решении Visual Studio, для вызовов других ссылочных сборок обычно используются заглушки. Это связано с тем, что внешние сборки, такие как System.dll, обычно не предоставляются с отдельными определениями интерфейса, поэтому вместо этого должны использоваться оболочки.

Однако существуют некоторые факторы, которые следует учитывать при использовании шима:

Производительность. Шимы выполняются медленнее, так как они перезаписывают код во время выполнения. Заглушки не имеют этой нагрузки на производительность и быстро выполняются виртуальные методы.

Статические методы, запечатанные типы: для реализации интерфейсов можно использовать только заглушки. Поэтому типы заглушки нельзя использовать для статических методов, не виртуальных методов, запечатанных виртуальных методов, методов в запечатанных типах и т. д.

Внутренние типы: заглушки и заглушки можно использовать с внутренними типами, доступными с помощью атрибута InternalsVisibleToAttributeсборки.

Частные методы. Сигнатуры могут заменить вызовы частных методов, если все типы в сигнатуре метода видны. Заглушки могут заменять только видимые методы.

Интерфейсы и абстрактные методы. Заглушки предоставляют реализации интерфейсов и абстрактных методов, которые можно использовать в тестировании. Оболочки не могут реализовать интерфейсы и абстрактные методы, поскольку они не имеют тел методов.

---

Переход Microsoft Fakes в платформа .NET Framework в проекты в стиле SDK

Переход платформа .NET Framework тестовых проектов, использующих Microsoft Fakes в проекты в стиле SDK платформа .NET Framework, .NET Core или .NET 5+.

Вам потребуется внести минимальные изменения в настройки .NET Framework для Microsoft Fakes, чтобы перейти на использование .NET Core или .NET 5.0. Ниже приведены требования, которые необходимо учитывать.

• Если вы используете шаблон пользовательского проекта, убедитесь, что он соответствует стилю пакета SDK и создан для совместимой целевой версии платформы.

• Некоторые типы существуют в разных сборках в .NET Framework и .NET Core/.NET 5.0 (например, System.DateTime существует в System/mscorlib в .NET Framework, а System.Runtime — в .NET Core и .NET 5.0). В этих сценариях необходимо изменить подделываемую сборку.

• Если имеется ссылка на сборку Fakes и тестовый проект, может появиться предупреждение сборки об отсутствии ссылки, подобное этому:

  (ResolveAssemblyReferences target) ->
  warning MSB3245: Could not resolve this reference. Could not locate the assembly "AssemblyName.Fakes". Check to make sure the assembly exists on disk.
  If this reference is required by your code, you may get compilation errors.
  

  Это предупреждение отображается, так как необходимые изменения, внесенные при создании сборки Fakes, можно игнорировать. Этого можно избежать, удалив ссылку на сборку из файла проекта, так как теперь мы неявно добавляем их во время сборки.

Запуск тестов Microsoft Fakes

Пока в настроенном каталоге FakesAssemblies имеются сборки Microsoft Fakes (по умолчанию $(ProjectDir)FakesAssemblies), можно запустить тесты с помощью задачи vstest.

Распределенное тестирование с помощью проектов .NET Core и .NET 5+ с помощью Microsoft Fakes требует предварительной версии 20201020-06 Visual Studio 2019 с обновлением 9 и выше.

Совместимость и поддержка Microsoft Fakes в разных версиях .NET и Visual Studio

Microsoft Fakes в старых проектах, предназначенных для .NET Framework (не в стиле пакета SDK).

• Создание сборки Microsoft Fakes поддерживается в Visual Studio Enterprise 2015 и более поздних версиях.
• Тесты Microsoft Fakes можно выполнять со всеми доступными пакетами NuGet Microsoft.TestPlatform.
• Объем протестированного кода поддерживается для тестовых проектов с помощью Microsoft Fakes в Visual Studio Enterprise 2015 и более поздних версиях.

Microsoft Fakes в проектах .NET Core, .NET Framework и .NET 5.0 или более поздней версии в стиле пакета SDK

• Создание сборки Microsoft Fakes, представленное в Visual Studio Enterprise 2019 (обновление 6), включено по умолчанию в обновлении 8.
• Тесты Microsoft Fakes для проектов, которые предназначены для .NET Framework, можно выполнять со всеми доступными пакетами NuGet Microsoft.TestPlatform.
• Тесты Microsoft Fakes для проектов, которые предназначены для .NET Core и .NET 5.0 или более поздней версии, можно выполнять с пакетами NuGet Microsoft.TestPlatform с версиями 16.9.0-preview-20210106-01 и выше.
• Объем протестированного кода поддерживается для тестовых проектов, которые предназначены для .NET Framework, с помощью Microsoft Fakes в Visual Studio Enterprise версии 2015 и более поздних.
• Поддержка покрытия кода для тестовых проектов, предназначенных для .NET Core и .NET 5.0 или более поздней версии, с помощью Microsoft Fakes, доступна в Visual Studio 2019 с обновлением 9 и более поздних версий.

Связанный контент

• Использование заглушек для изоляции частей приложений друг от друга при модульном тестировании
• Использование оболочек совместимости для изоляции приложения от других сборок при модульном тестировании
• Формирование и компиляция кода, а также соглашения об именовании в Microsoft Fakes