Сборка NUnit

NUnit 3 состоит из трёх отдельных слоёв: Framework, Engine и Console Runner. Исходный код хранится в двух репозиториях GitHub: https://github.com/nunit/nunit и https://github.com/nunit/nunit-console.

Исходный код

У вас не будет разрешения на создание веток непосредственно в любом из указанных выше репозиториев, поэтому вам нужно будет работать над локальным форком.

Процесс разработки для внесения изменений в код и отправки запросов на вытягивание (PR) выглядит следующим образом:

1. Создайте форк репозитория NUnit.
2. Клонируйте форк на свой компьютер.
3. Внесите изменения в новую ветку.
4. Убедитесь, что все тесты NUnit проходят локально (т. е. запустите их во всех целевых фреймворках и на как можно большем количестве платформ, которые у вас есть, например Windows, Linux, Mac). Раздел «Сборка скрипта» ниже содержит точные инструкции о том, как это сделать из командной строки / терминала.
5. Отправьте ветку в свой форк.
6. Создайте PR (более подробно описано здесь).

Сборка решения

Существует одно решение Visual Studio, nunit.sln, которое находится в корне репозитория NUnit.

Фреймворк NUnit можно собрать из этого решения с помощью IDE, совместимой с .NET 6, такой как:

• Visual Studio 2022 или более новая версия (Windows);
• Visual Studio for Mac (macOS);
• Visual Studio Code — скомпилируйте с использованием сценария сборки вместо VS Code (подробности см. ниже).
• Jetbrains Rider.

На всех платформах вам потребуется установить .NET 6.0 SDK или более новую версию.

В macOS или Linux вам потребуется установить Mono, открытую реализацию Microsoft .NET Framework. Версия Mono 6.12.0 Stable (6.12.0.122) была проверена для создания решения NUnit в GNU/Linux Debian 10 'buster'.

Сборка решения помещает все свои выходные данные в общий каталог bin под каталогом решения.

Поскольку решение NUnit нацелено на несколько фреймворков, одна сборка создаст файлы для каждого целевого фреймворка. Например, отладочная сборка создаёт следующую структуру каталогов:

(каталог с nunit.sln)
bin\
   Debug\
      net8.0
      net6.0
      net462

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

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

• nunit.framework.tests-*;
• nunitlite.tests-.

Другие тестовые проекты содержат тесты, предназначенные для преднамеренного сбоя для интеграционных тестов.

Затем вы сможете запустить модульные тесты прямо из выбранной вами среды разработки против одной или всех целевых платформ (как при использовании NUnit в любом другом проекте разработки). Например, вот как это выглядит в JetBrains Rider (2021.1.2), когда вы щёлкаете правой кнопкой мыши на TextFixture AssertEqualsTests:

Известные проблемы и обходные пути

К сожалению, в настоящее время существуют некоторые известные проблемы со сборкой и запуском тестов локально.

Тесты не будут запускаться в Rider или Visual Studio (#3008)

Вы можете запустить NUnit Lite аналогичным образом, но из среды разработки после успешной сборки.

Вероятно, это самый простой способ (пока проблема #3008 остаётся открытой) для разработчиков пошагово выполнять код и отлаживать любые новые вклады в кодовую базу.

Убедитесь, что в вашей среде разработки есть конфигурация запуска/отладки, которая указывает nunitlite-runner в качестве запускаемого проекта.

Затем укажите аргументы программы точно так же, как указано выше. Например, следующий аргумент nunit.framework.tests.dll --where "class == NUnit.Framework.Assertions.AssertEqualsTests" запустит все тесты в TextFixture NUnit.Framework.Assertions.AssertEqualsTests в nunit.framework.tests.dll. Построение скрипта

Мы используем Cake для сборки NUnit для распространения. Основной скрипт, который управляет сборкой, запуском тестов и упаковкой — это build.cake. Мы модифицируем build.cake, когда нам нужно добавить новые цели или изменить способ сборки. Обычно build.cake вызывается не напрямую, а через build.ps1 (PowerShell в Windows) или build.sh (bash в Linux). Эти два скрипта предоставляются проектом Cake и обеспечивают правильную установку Cake перед попыткой запуска скрипта cake.

Ключевые аргументы для build.ps1/ build.sh:

Скрипт build.cake содержит большое количество взаимосвязанных задач. Наиболее важные задачи верхнего уровня перечислены здесь:

Например, следующая команда .\build.ps1 --target=Test --configuration=Release (PowerShell на Windows) выполнит полную сборку релиза для всех целевых фреймворков, а затем выполнит модульные тесты для каждой цели.

Для получения полного списка задач запустите .\build.ps1 --showdescription (PowerShell на Windows) или ./build.sh --showdescription (bash на Linux).

Примечания

1. По замыслу, цель Package не зависит от Build. Это позволяет при необходимости переупаковывать без изменения самих двоичных файлов. Конечно, это означает, что вы должны быть очень осторожны, чтобы сборка была актуальной перед упаковкой.
2. Для дополнительных целей обратитесь к самому скрипту build.cake.

Определённые константы

NUnit часто использует условный препроцессор для включения API и поведения на разных платформах.

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

Константы функций определены в Directory.Build.props:

• THREAD_ABORT включает тайм-ауты и принудительное прерывание.

Константы платформы определяются условно SDK csproj, по одной для каждого целевого фреймворка. Например, NET462, NETSTANDARD2_0, NET6_0 и так далее. В данном сценарии наиболее полезно указать, какие платформы являются исключением, а не правилом. Помните о влиянии, которое препроцессор окажет на вновь добавленную платформу.

Например, вместо этого кода:

#if NETSTANDARD2_0 || NET6_0
// Something that .NET Framework can't do
#endif

Рассмотрите это:

#if !NETFRAMEWORK
// Something that .NET Framework can't do
#endif

Или это для обратного:

#if NETFRAMEWORK
// Something that only .NET Framework can do
#endif