Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Изоляция кода — это стратегия тестирования, часто реализованная с помощью таких средств, как Microsoft Fakes, где тестируемый код отделен от остальной части приложения. Это разделение достигается заменой частей приложения, которые взаимодействуют с тестируемым кодом, на заглушки или прослойки. Это небольшие фрагменты кода, контролируемые тестами, которые имитируют поведение фактических частей, которые они заменяют.
Преимуществом этого подхода является то, что он позволяет сосредоточиться на тестировании конкретных функциональных возможностей кода в изоляции. Если тест завершается ошибкой, вы знаете, что причина находится в изолированном коде, а не в другом месте. Кроме того, использование заглушек и подмен из Microsoft Fakes позволяет тестировать код, даже если другие части приложения пока не работают.
Требования
- Visual Studio Enterprise
- Проект .NET Framework
- .NET Core, .NET 5.0 или более поздней версии и поддержка проекта в стиле SDK в Visual Studio 2019 и более поздних версий. Дополнительные сведения см. в статье Microsoft Fakes для проектов .NET Core и SDK-стиля.
Note
Профилирование в Visual Studio недоступно для тестов, в которых используется Microsoft Fakes.
Роль Microsoft Fakes в изоляции кода
Microsoft Fakes играет ключевую роль в изоляции кода, предоставляя два механизма — заглушки и шимы.
Заглушки: Они используются для замены класса небольшим объектом-заменителем, реализующим тот же интерфейс. Это требует, чтобы приложение было разработано таким образом, чтобы каждый компонент зависел только от интерфейсов, а не от других компонентов.
Шимы: они используются для изменения скомпилированного кода приложения во время выполнения. Вместо вызова указанного метода приложение запускает код схима, который предоставляет тест. Shims могут заменять вызовы к сборкам, которые нельзя изменить, например, сборки .NET.
Как правило, заглушки используются для вызовов в решении Visual Studio, а также для вызовов других ссылочных сборок. Это связано с тем, что в вашем решении рекомендуется разделить компоненты, определив интерфейсы таким образом, что требуется привязывание. Однако внешние сборки часто не имеют отдельных определений интерфейса, поэтому вместо этого используются оболочки.
Рекомендации о том, когда следует использовать заглушки
Заглушки обычно используются при вызовах внутри вашего решения Visual Studio, поскольку считается хорошей практикой разделять компоненты, определяя интерфейсы так, как это требуется для использования заглушек. Однако внешние сборки, такие как System.dll, обычно не поставляются с отдельными определениями интерфейсов, поэтому в таких случаях вместо этого используются шимы.
Использование заглушек предполагает проектирование приложения таким образом, чтобы различные компоненты зависели не друг от друга, а только от определений интерфейсов. Такое разделение делает приложение более надежным и гибким, а также позволяет подключать тестируемый компонент к фиктивным реализациям интерфейсов в целях тестирования.
На практике в Visual Studio можно создать типы-заглушки на основе определений интерфейсов, а затем в тесте заменить реальный компонент заглушкой.
Рекомендации о том, когда следует использовать шимы
Хотя заглушки используются для вызовов в рамках решения Visual Studio, шимы обычно используются для вызовов других подключенных сборок. Это связано с тем, что внешние сборки, такие как System.dll, обычно не содержат отдельных определений интерфейсов, поэтому вместо них следует использовать shim-объекты.
Однако существуют некоторые факторы, которые следует учитывать при использовании шима:
Производительность: Шимы работают медленнее, поскольку они переписывают ваш код во время выполнения. Заглушки не имеют таких накладных расходов на производительность и работают так же быстро, как виртуальные методы.
Статические методы, закрытые типы: для реализации интерфейсов можно использовать только заглушки. Поэтому типы-заглушки нельзя использовать для статических методов, невиртуальных методов, запечатанных виртуальных методов, методов в запечатанных типах и т. д.
Внутренние типы: и stubs, и shims можно использовать с внутренними типами, к которым предоставлен доступ с помощью атрибута сборки InternalsVisibleToAttribute.
Частные методы. Сигнатуры могут заменить вызовы частных методов, если все типы в сигнатуре метода видны. Заглушки могут заменять только видимые методы.
Интерфейсы и абстрактные методы: Заглушки содержат реализации интерфейсов и абстрактных методов, которые можно использовать при тестировании. Шимы не могут инструментировать интерфейсы и абстрактные методы, поскольку у них нет тел методов.
Перенос Microsoft Fakes в .NET Framework в проекты в стиле SDK
Перевод тестовых проектов .NET Framework, использующих Microsoft Fakes, на проекты .NET Framework в стиле SDK, .NET Core или .NET 5+
Для перехода Microsoft Fakes на .NET Core или .NET 5.0 потребуются лишь минимальные изменения в конфигурации .NET Framework. Рассмотрим следующие случаи:
Если вы используете пользовательский шаблон проекта, необходимо убедиться, что шаблон выполнен в стиле 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
Пока сборки Microsoft Fakes присутствуют в указанном каталоге FakesAssemblies (по умолчанию — $(ProjectDir)FakesAssemblies), вы можете запускать тесты с помощью задачи vstest.
Для распределённого тестирования проектов .NET Core и .NET 5+ с использованием Microsoft Fakes с помощью задачи vstest требуется Visual Studio 2019 Update 9 Preview 20201020-06 или более поздняя версия.
Совместимость и поддержка 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 в проектах в стиле SDK для .NET Framework, .NET Core и .NET 5.0 и более поздних версий
- Создание сборок Microsoft Fakes было представлено в предварительной версии Visual Studio Enterprise 2019 Update 6 и включено по умолчанию в Update 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.