Внедрение зависимостей, покрытие кода, отладка и многое другое

Я люблю VS Code. Мне также нравятся функции Azure Durable Functions. А модульное тестирование - это очень мило. Сложите их все вместе, и вы получите ... несколько неизведанную территорию.

Большинство принципов модульного тестирования .NET Core 2 применимы к надежным функциям, но есть несколько дополнений. Особенно, если вы используете только Visual Studio Code. Это должно помочь вам начать с:

  • Настройка проекта
  • Пакеты и расширения
  • Внедрение зависимостей и функции Azure
  • Тестирование долговечных функций
  • Запуск тестов
  • Покрытие кода
  • Отладка модульных тестов

Настройка проекта

Модульные тесты .NET должны находиться в отдельном каталоге с собственным проектом, являясь частью всего решения. Предполагая, что у вас уже есть код для тестирования в каталоге src, выполните следующие действия, чтобы настроить свой тестовый каталог:

  1. Создайте новый каталог для размещения модульных тестов. test, наверное, хорошее имя.
  2. Создайте проект модульного тестирования
    a. Перейти в каталог с тестами
    b. Выполнить dotnet new mstest (Создает новый проект модульного теста с помощью MSTest) Вы также можете передать NUnit или xUnit.
    c. Добавьте основной проект (ы) в этот тестовый проект - dotnet add reference ../src/MyProject.csproj
  3. Вернитесь в корневой каталог и добавьте в решение проект модульного теста - dotnet sln add test/MyProject.Tests.csproj

Пакеты и расширения

Вам нужно установить следующие пакеты в проект unit test.

  • Moq - Для насмешек и заглушек.
  • Coverlet - Для кроссплатформенного покрытия кода

Также рекомендуются следующие расширения VS Code:

  • .NET Core Test Explorer - пользовательский интерфейс для запуска тестов.
  • Coverage Gutters - отображать закрытые строки кода прямо в VS Code.

Внедрение зависимостей и функции Azure

Из-за static природы Функций Azure в настоящее время они не поддерживают внедрение зависимостей (DI). Это проблема, поскольку DI является обязательным условием модульного тестирования на C #. К счастью, есть способы реализовать DI. Это самый простой способ, который я нашел.

  1. Установите этот пакет, который содержит расширения привязки для внедрения зависимостей.
  2. Создайте файл в корне основного проекта с именем Startup.cs со следующим содержимым:

3. Это работает очень похоже на обычный проект .NET Core, где вы можете добавить ссылки на одноэлементные файлы в файл запуска.

4. Обратите внимание, что ConfigureServices - это место, где вы создаете экземпляры своих абстрактных функций или интерфейсов. В приведенном выше примере мы создаем экземпляр ISendGridClient (для отправки электронных писем). Затем мы добавляем его как синглтон, и теперь каждый раз, когда ISendGridClient Injected, этот экземпляр будет передан.

5. Теперь модульные тесты могут проходить в своих собственных mock-объектах класса, как обычно:

Примечание. Существует известная проблема, при которой в Azure возникают ошибки. Согласно документации, у меня есть обходной путь. Поместите этот файл Directory.Build.target в корень вашего приложения-функции. Это скопирует отсутствующий файл в Azure.

Тестирование долговечных функций

Долговечные функции довольно уникальны в мире C #. Так что следует ожидать, что их тестирование тоже довольно уникально. Любая нормальная функция в проекте Durable Function, конечно, может быть протестирована как обычно. Для тех, кто относится к долговечным функциям, выполните следующие действия. См. Эту статью от Microsoft для получения дополнительной информации.

Закуски

Вы должны добавить Base к параметру DurableOrchestrationClient.

Этот DurableOrchestrationClientBase класс теперь можно смоделировать, а затем передать непосредственно стартовой функции.

Начинающие HTTP

У HTTP-стартеров есть параметр HttpRequestMessage, который нелегко высмеять (вообще)! См. Пример TestHelper файла, который выполняет необходимую настройку в this Gist.

Когда у вас есть функция SetupHttp, вы можете использовать ее в этом полном примере следующим образом:

Оркестраторы

Вы должны добавить Base к параметру DurableOrchestrationContext.

Этот класс DurableOrchestrationContextBase теперь можно смоделировать, а затем передать непосредственно в функцию оркестратора.

мероприятия

Действия можно тестировать так же, как и любую другую функцию .NET. Вы можете просто передать параметр, как обычно, несмотря на декоратор ActivityTrigger

Вы можете просто передать MyClass модель напрямую, как обычно. Если вы используете DurableActivityContext вместо модели напрямую, например:

В настоящее время не существует Base класса, над которым можно было бы издеваться. Но в настоящее время это находится в ветке разработки Durable Functions. Убедитесь, что требуется thatDurableActivityContext, вы можете просто использовать модель напрямую. Если нет, то жестко 😃. Приближается!

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

Попав в каталог тестирования, dotnet test - самый простой способ запускать тесты. Вы также можете запустить dotnet watch test, и тесты будут запускаться повторно каждый раз, когда вы меняете файл.

Если вам не нравится печатать, вы можете создать задачу в VS Code. Откройте tasks.json и добавьте следующий фрагмент JSON. Обязательно замените материал MyProject на местоположение вашего проекта.

Затем вы можете открыть палитру команд VS Code и запустить «Задачи: выполнить тестовую задачу».

Покрытие кода

Покрытие кода встроено в .NET Core, но не работает на кроссплатформенных платформах. Вместо этого мы воспользуемся установленным ранее пакетом Coverlet. Чтобы запустить тест с включенным покрытием кода, вы можете запустить dotnet test /p:CollectCoverage=true.

Расширение Coverage Gutters, которое мы установили ранее, может отображать покрытые строки прямо в VS Code.

Для этого требуется определенный формат файла. Чтобы создать файл правильного формата, выполните эту очень короткую команду:

dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=lcov /p:CoverletOutput=./lcov.info

Это просто указывает dotnet собирать покрытие и создавать его в формате lcov, который требуется для Coverage Gutters. Затем вы можете использовать палитру команд и запустить либо «Промежутки покрытия: отображение покрытия», либо «Промежутки покрытия: наблюдение». Часы - это круто, потому что они автоматически обновляются по мере добавления тестов. В сочетании с dotnet watch test все это довольно удобно и автоматизировано.

Отладка модульных тестов

Отладка - это весело и необходимо. Это не очень хорошо сочетается со всеми вышеперечисленными забавными вещами, но все же выполнимо.

Во-первых, вам нужна команда отладки для присоединения к процессу. Откройте launch.json и добавьте новую конфигурацию:

Это позволит вам подключить отладчик VS Code к любому процессу. Давайте подготовим VS Code для этого.

  • Выполните команду export VSTEST_HOST_DEBUG=1. Это говорит VS-коду подготовиться к некоторой отладке.
  • Беги dotnet test
  • Вместо того, чтобы запускать тесты, он будет ждать, пока вы подключитесь к процессу:
Host debugging is enabled. Please attach debugger to testhost process to continue.
Process Id: 60143, Name: dotnet

  • Запустите вашу .NET Core Attach команду на вкладке отладки. Выберите идентификатор процесса, который был показан ранее (60143 в этом примере).

  • Почти готово. Все это подключает вас, но еще не совсем в ваши тесты. На вкладке «Стек вызовов» вы должны увидеть что-то с надписью «‹ Без имени ›Приостановлено на точке останова».
  • Нажмите «Приостановлено на точке останова», теперь вы можете нажать «Продолжить» в отладчике, и вы должны перейти к первой установленной вами точке останова!
  • Когда вы выясните свою проблему, вы можете запустить export VSTEST_HOST_DEBUG=0, чтобы вернуться в нормальное состояние.

Заключение

Вот и все! Надеюсь, вы нашли это полезным. В этом есть кое-что, но после небольшой настройки вы можете делать практически все, что захотите, в VS Code для модульного тестирования устойчивых функций.