с помощью какого атрибута можно установить максимальное время выполнения теста nunit

Как я могу запустить тесты NUnit параллельно?

У меня есть большой приемочный тест (

10 секунд на тест), написанный с использованием NUnit. Я хотел бы использовать тот факт, что все мои машины являются многоядерными. В идеале я бы мог провести один тест на ядро ​​независимо от других тестов.

Существует PNUnit, но он предназначен для тестирования потоков с синхронизацией и тому подобного, и я не видел очевидного способа добиться этого.

Есть ли переключатель/инструмент/опция, которую я могу использовать для параллельного запуска тестов?

Стандартный nunit runner не поддерживает параллельное выполнение тестов. Вы можете создать собственный тестовый прогон для параллельного запуска тестов (используя текущие тесты nunit). Я не уверен, почему бригада не сделала этого уже.

Кроме того, MBUnit имеет возможность создания распараллеливаемых тестов, и поскольку MBUnit имеет почти такой же синтаксис, что и NUnit, для переключения может потребоваться не так много усилий.

EDIT: Как отмечалось в комментариях, хотя этот ответ был верным на момент написания статьи, если вы хотите запустить тесты NUnit параллельно, есть как минимум 2 варианта:

NUnit версии 3 будет поддерживать параллельное выполнение тестов:

Добавление атрибута в класс: [Parallelizable(ParallelScope.Self)] запустит ваши тесты параллельно.

• ParallelScope.None указывает, что тест не может выполняться параллельно с другими тестами.

• ParallelScope.Self указывает, что сам тест может выполняться параллельно с другими тестами.

• ParallelScope.Children указывает, что потомки теста могут выполняться параллельно друг другу.

• ParallelScope.Fixtures указывает, что приборы могут работать параллельно друг с другом.

Если ваш проект содержит несколько тестовых DLL, вы можете запускать их параллельно, используя этот скрипт MSBuild. Очевидно, вам нужно настроить пути в соответствии с макетом вашего проекта.

Для работы с 8 ядрами запустите: c:\proj> msbuild /m:8 RunTests.xml

RunTests.xml

В эта статья упоминается, что для ускорения тестов постер запускает несколько экземпляров NUnit с параметрами команды, указывающими, какие тесты должен запускать каждый экземпляр.

Я столкнулся со странной проблемой.

nunit-console-x86.exe Model.dll Test.dll/исключить: MyCategory /xml=TestResults.xml /framework=net-4.0/noshadow

nunit-console-x86.exe Model.dll Test.dll/включает в себя: MyCategory /xml=TestResults.xml /framework=net-4.0/noshadow

Если мы выполним команды в последовательности, обе команды будут выполнены успешно. Но если мы выполним их параллельно, это удастся только одному. Насколько я могу судить, именно он первым загружает тестовые приборы. Другой сбой с сообщением «Невозможно найти прибор».

Эта проблема уже известна? Я не смог найти ничего связанного в списке ошибок на панели запуска. Кстати, наш сервер работает под управлением Windows Server 2008 64-bit. Я также мог воспроизвести проблему на Windows 7 64-битной.

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

Update

Таким образом, теоретически вы можете заставить TeamCity автоматически запускать несколько тестов NUnit, основываясь на том, что вы хотите разделить рабочую нагрузку, а затем объединить результаты в один файл для обработки после тестирования.

Это достаточно автоматизировано для ваших нужд?

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

Теперь вы можете использовать NCrunch для распараллеливания ваших модульных тестов, и вы даже можете настроить, сколько ядер должно использоваться NCrunch и сколько должно использоваться Visual Studio.

плюс вы получаете постоянное тестирование в качестве бонуса 🙂

Правка: похоже, что они добавили параметр/process в консольное приложение. В справке командной строки указано, что это «Модель процесса для тестов: один, отдельный, несколько». Испытательный бегун также, кажется, имеет эту функцию.

Правка 2: К сожалению, хотя он создает отдельные процессы для каждой сборки, опция изоляции процесса (/ process из командной строки) запускает агентов по одному.

Вы можете попробовать мой маленький инструмент TBox или консольную параллель Runner или даже плагин для выполнения распределенных вычислений, который также может запускать модульные тесты на множестве ПК SkyNet

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

Также это поддержка:

Клонирование папки с юнит-тестом (если ваши тесты изменяют локальные данные),

Синхронизация тестов (например, если ваши тесты на testfixtureteardown убивают все dev-серверы или chromerunner для qunit)

режим x86 и права администратора для запуска тестов

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

Также этот инструмент поддерживает запуск командной строки тестов (для параллельного запуска), и вы можете использовать его с непрерывной интеграцией.

Источник

Модульное тестирование кратко: NUnit

Это отрывок из электронной книги «Единичное тестирование » Марка Клифтона, любезно предоставленный Syncfusion.

В следующей таблице сопоставляются атрибуты, используемые для написания тестов с NUnit с Visual Studio:

Атрибут Visual Studio

Определяет тестовый прибор

Определяет метод теста в классе тестового прибора

Задает код, который запускается перед запуском всех методов тестирования в тестовом приборе.

Задает код, который запускается после завершения всех тестов в приборе.

Определяет код для запуска перед выполнением каждого теста.

Определяет код для запуска при завершении каждого теста.

SetUpFixture (см. Ниже)

Задает код, который запускается при загрузке сборки, содержащей все тестовые приборы.

SetUpFixture (см. Ниже)

Задает код, который запускается при выгрузке сборки, содержащей все тестовые приборы.

Игнорирует конкретный тест.

Описание (также относится к тестовым приборам).

Описание метода испытаний. В NUnit этот атрибут также может украшать тестовое устройство.

Следующие атрибуты Visual Studio не соответствуют никаким атрибутам NUnit:

Атрибут SetUpFixture

Атрибут SetUpFixture, который применяется к классам, отличается от AssemblyInitialize и AssemblyCleanup в Visual Studio, поскольку он применяется к осветителям в данном пространстве имен. Если все ваши классы тестовых приборов находятся в одном и том же пространстве имен, то этот атрибут ведет себя аналогично AssemblyInitialize и AssemblyCleanup. Учитывая код:

В результате получается:

Тем не менее, добавив еще одно пространство имен:

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

Также см. «Действия сборки» в разделе «Определенные пользователем атрибуты действий» в следующем разделе.

Дополнительные атрибуты NUnit

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

Тестовая группировка и контроль

категория

Атрибут Category позволяет группировать тесты и запускать тесты в выбранных категориях. Этот атрибут может применяться к тестам в приборе, а также к отдельным тестам в приборе. Определенные категории могут быть выбраны в консоли приложения, используя аргументы / include и / exclude, или в программе запуска GUI:

NUnit Категории

Вкладка для выбора категорий для включения или исключения находится на левом краю бегунка GUI.

свита

Атрибут Suite предоставляет возможность программно определять тестовые устройства, которые должен тестировать участник консоли. Эта опция доступна только в консоли. Концепция запуска только определенных тестов или наборов тестов (приспособлений) лучше поддерживается атрибутом Category, описанным ранее.

Явный

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

Использование этого атрибута — запуск только длительных тестов, когда это явно требуется, когда служба запущена и т. Д.

Тайм-аут

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

Сравните этот атрибут с атрибутом MaxTime, описанным ниже.

Также обратите внимание, что при запуске модульных тестов в отладчике атрибут Timeout игнорируется — в противном случае отлаживаемый тест может завершиться, поскольку вы вручную просматриваете код, просматриваете значения и т. Д.

Атрибуты культуры

культура

Атрибут Культура может использоваться для прибора, чтобы определить культуры, для которых должны выполняться тесты. Тесты, которые специфичны для конкретной культуры, также должны быть украшены этим атрибутом, описывающим тестируемые культуры. Тест или прибор пропускаются, если текущая культура не соответствует культуре, для которой написан тест. Например:

В предыдущем коде прибор работает, если текущая культура имеет значение «fr» или «en»; тем не менее, TestA указывает, что тест должен выполняться только в том случае, если для культуры задано значение «fr.». Следовательно, это устройство приведет к:

Культурное тестирование

поскольку «TestA» не запускается, потому что текущая культура не «фр.»

Такие тесты, как «TestB», в которых не указана какая-либо спецификация культуры, всегда выполняются, если только весь прибор не исключен, поскольку текущая культура не соответствует.

SetCulture

Этот атрибут, применяемый ко всему устройству или определенным тестам, устанавливает текущую Культуру на время теста (или тестов в приборе), а затем восстанавливает исходное значение. В отличие от атрибута Культура до этого, можно указать только одну культуру, хотя в соответствии с документацией NUnit, запуск тестов для нескольких культур запланирован как будущее усовершенствование. Обратите внимание, что настройка культуры в устройстве не влияет на выполнение теста с использованием атрибута Культура. Например:

результаты в TestA не работает. Также обратите внимание на поведение TestB по умолчанию, когда культура установлена ​​в приборе и как она переопределяется в TestC:

Переопределение в TestC

SetUICulture

Этот атрибут должен устанавливать культуру для пользовательского интерфейса; однако, это очевидно ничего не делает. Например (не пишите модульный тест, как это, это только для иллюстрации):

приводит к значению «1.2», отображаемому в моей текущей культуре, будучи en-US:

Атрибут SetUICulture ничего не делает

Если я изменю атрибут на «SetCulture», то пользовательский интерфейс отобразит значение в правильном формате культуры (возможно, вам придется щуриться, чтобы увидеть разницу между «1 балл 2» и «1 запятая 2»:

SetCulture изменяет представление пользовательского интерфейса

Параметризованные тесты

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

Например, этот тест:

приводит к следующему выводу (и обратите внимание, что график теста также отображает параметры теста):

Параметризованные тесты

Следующие атрибуты используются для параметризованного тестирования:

Ценности

Как показано в предыдущем примере, атрибут Values ​​используется для указания значений, передаваемых в метод теста для каждого параметра. Поскольку это значения, назначенные в атрибуте, они должны иметь тип значения: константные выражения, выражения typeof или массив типов атрибутов.

Также обратите внимание, что NUnit по умолчанию будет проверять каждую комбинацию значений для каждого параметра (см. Атрибуты Combinatorial, Pairwise и Sequential).

ValuesSource

С атрибутом ValueSource вы можете указать источник IEnumerable для значений определенного параметра. Источником может быть поле, свойство или метод отдельного класса или текущего класса. Например, все это допустимые способы выражения источников стоимости:

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

Тесты ValueSource

комбинаторный

Этот атрибут является необязательным, поскольку NUnit автоматически применяет параметры теста во всех возможных комбинациях. Например:

приводит ко всем комбинациям «x» и «s», независимо от того, указано «Combinatorial»:

Комбинаторный тест

парный

Этот атрибут существует, но не реализован — он предназначен для уменьшения количества комбинаций, когда заданы комбинаторные параметры; однако этот атрибут игнорируется.

последовательный

Этот атрибут указывает, что тесты будут выполняться путем последовательного перехода по значениям параметров. Если количество значений не одинаково для каждого параметра, будет использоваться значение по умолчанию. Обратите внимание, что значение по умолчанию для строки равно нулю. Например, этот код, используя атрибут Sequential:

Результаты в этом выводе:

Последовательный атрибут

Обратите внимание, что строка (имеющая только два значения) по умолчанию равна нулю для двух последних параметризованных тестов, а параметр int, имеющий три случая, по умолчанию равен 0 для последнего случая.

случайный

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

Результаты в пяти тестах со случайными значениями:

Случайный тест

Минимальный и максимальный значения также могут быть указаны для диапазона случайных значений.

С помощью комбинаторных параметризованных тестов легко создать сотни, если не тысячи тестовых случаев. Попробуйте использовать атрибут Sequential, чтобы предотвратить тестирование большого количества комбинаций. Атрибут Sequential, примененный к тесту, может использоваться вместе с атрибутом Random в параметрах теста.

Ассортимент

Атрибут Range указывает диапазон значений для тестирования. За исключением целочисленного диапазона, другие диапазоны (long, float, double) требуют указания шага. Шаг для целочисленных значений не является обязательным.

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

Прецедент

Вместо комбинаторного или последовательного параметризованного теста вы можете явно определить значения параметров, передаваемых в каждый тестовый набор для запуска для конкретного теста. Преимущество этого заключается в уменьшении количества комбинаторных тестов, а также в нацеливании на конкретные сценарии тестирования. Кроме того, атрибут TestCase включает в себя дополнительную характеристику возможности проверять возвращаемое значение (при условии, что это тип «значение») со значением, указанным в метаданных атрибута. Наконец, дополнительные свойства, такие как атрибуты зеркального отображения, отображаются в атрибуте TestCase.

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

Однако реальная сила атрибута TestCase заключается в возможности напрямую применять тестовые примеры к методу и проверять результат:

Помните, что значения, указанные в атрибутах, должны быть типами значений: константное выражение, выражение typeof или выражение создания массива типа параметра атрибута.

Также имейте в виду, что атрибут TestCase может побуждать помещать тестовые наборы в ту же сборку, что и рабочий код, а не в отдельную тестовую сборку — атрибуты не удаляются в сборке выпуска сборки. При использовании атрибута TestCase рекомендуется не применять атрибут непосредственно к коду, для которого вы хотите тестовые случаи, а скорее к самому тестовому устройству. Так что в идеале правильный код должен выглядеть примерно так:

в котором класс MyMath находится в сборке приложения, а тестовое устройство — в сборке модульного теста. Затем метод DivideTest становится тонкой оболочкой для метода приложения.

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

Есть также альтернативы, указывающие ожидаемое исключение:

который позволяет вам указать полное имя (соответствующее значению свойства Type.FullName) или сообщение об исключении, а также способ сопоставления сообщения об исключении — Contains, Exact, Regex или StartsWith.

TestCaseSource

Атрибут TestCaseSource ведет себя подобно атрибуту ValueSource, описанному ранее; однако предпочтительной реализацией является указание типа класса, который реализует IEnumerable. Эта предпочтительная реализация ограничивает вас чем-то вроде этого:

Обратите внимание, что значения тестового примера — это int [] (целочисленный массив), в котором каждый элемент массива отображается на параметр в тестовой функции. Также отметьте еще раз, что атрибут Sequential указан для теста, гарантируя, что данные теста используются последовательно, а не комбинаторно.

Другие атрибуты NUnit

Есть несколько других атрибутов NUnit, описанных далее.

Платформа

Атрибут Platform может использоваться для указания платформы, для которой должен выполняться тест. Если платформа не соответствует текущей платформе, тест не запускается и даже не включается в игнорируемые тесты или общее количество тестов. Просмотрите документацию по адресу http://www.nunit.org/index.php?p=platform&r=2.6.2, чтобы увидеть список поддерживаемых спецификаторов платформы.

Свойство

Вы можете использовать этот атрибут для установки пары имя или значение в тесте или приборе, которые затем отображаются в выходном файле XML. Через отражение вы можете получить доступ к этим атрибутам. Настраиваемые атрибуты свойств также могут быть созданы путем получения настраиваемого класса атрибутов из класса PropertyAttribute.

MaxTime

Атрибут MaxTime (если сравнивать с атрибутом Timeout, описанным ранее) приведет к сбою теста, если он превысит указанное время в миллисекундах. Однако, в отличие от атрибута Timeout, тест будет разрешено завершить.

Повторение

Атрибут Repeat может применяться только к тестам и игнорируется для параметризованных тестов. Он инструктирует тестовый двигатель повторить тест указанное количество раз. Если какое-либо повторение теста не удается, остальные тесты не запускаются, и двигатель сообщает об ошибке.

RequiredAddin

С помощью этого атрибута вы можете указать дополнительные сборки (в файле AssemblyInfo), которые требуются для модульных тестов.

RequiresMTA

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

Если для всего устройства создан поток, все тесты в этом устройстве выполняются в новом потоке.

RequiresSTA

Этот атрибут, примененный к тесту или устройству, указывает, что тест должен выполняться в однопоточной квартире. NUnit создаст новый поток для теста, если:

Если для всего устройства создан поток, все тесты в этом устройстве выполняются в новом потоке.

RequiresThread

Этот атрибут, примененный к тесту или устройству, указывает, что тест должен выполняться в отдельном потоке. NUnit создаст новый поток, если этот атрибут указан в файле AssemblyInfo:

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

Если в тесте указан этот атрибут, тест будет выполняться во вновь созданном потоке.

Дополнительно можно указать состояние квартиры, что приводит к созданию потока MTA или STA.

Обратите внимание на идентификаторы потоков при выполнении теста:

Примеры потоков

Тест A и Тест C выполняются в потоке, созданном прибором, тогда как Тест B, указав атрибут RequThread, выполняется в отдельном потоке от потока других тестов в этом приборе.

Теория и Datapoint (s)

Теория — это параметризованный тест, который проверяет допущения о передаваемых значениях. Если допущение не выполняется, тест не проходит. Работает с атрибутом Datapoint (s).

Эти два класса эквивалентны. Первый иллюстрирует использование атрибута Datapoint, второй — атрибут Datapoints:

Обратите внимание, что в первом классе, TheoryExample1, используются дискретные значения точек данных, тогда как во втором классе, TheoryExample2, используется массив.

В обоих случаях NUnit создаст все возможные комбинации значений из точек данных. Обратите внимание, как метод теста делает определенные предположения:

Причина второго предположения заключается в том, что тест не пройден для большинства комбинаций — например, 5/10 не равен 2. Как видно из прогона теста, допущения не приводят к провалу теста:

Теории

Комбинации значений параметров, которые не соответствуют допущениям, в тесте не учитываются. Типичный образец для теоретического теста:

Следует соблюдать осторожность при проверке теории из-за растущего числа комбинаций аргументов.

Также обратите внимание, что если явно не указано, NUnit автоматически заполняет комбинации значений параметров для типов bool и enum.

Определенные пользователем атрибуты действий

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

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

Определение действия

Пользовательское действие является производным от TestActionAttribute:

или может быть получен из System.Attribute и реализовать интерфейс ITestAction:

В последнем случае также должно быть определено свойство «Цели».

Цели действий

Цель действия (либо прибор, либо набор) или метод тестирования можно определить с помощью перечисления ActionTargets (определено в NUnit.Framework):

ActionTargets.Default

Указание значения ActionTargets.Default позволяет применять определенный пользователем атрибут как к тестовым осветителям (классам), так и к тестам (методам). Однако при применении к осветителю (классу) атрибут ведет себя так, как если бы был указан ActionTargets.Suite — определяемое пользователем действие выполняется один раз для всего набора тестов.

ActionTargets.Test

Если ActionTargets.Test возвращается пользовательским действием, это меняет поведение при вызове пользовательского действия. Применительно к устройству (классу) пользовательское действие выполняется для каждого теста. Если пользовательский атрибут применяется к определенному тесту, то для этого конкретного теста выполняется пользовательское действие.

ActionTargets.Suite

Если цель действия атрибута является набором, но используется в контексте метода тестирования, об ошибке не сообщается — действие просто не выполняется.

Тест и целевые наборы действий

ActionTargets являются флагами, поэтому их можно комбинировать:

указать, что пользовательское действие должно выполняться как для прибора (набор тестов), так и для отдельных тестов.

Класс TestDetails

Этот класс создается с информацией о готовящемся приборе или тесте (из NUnit.Framework.TestDetails):

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

Действия Ассамблеи

Придерживаясь большего в концепции Visual Studio для AssemblyInitialize и AssemblyCleanup, вы можете использовать пользовательское действие на основе сборки. Например, с предыдущим кодом, если в файл AssemblyInfo.cs добавлена ​​следующая строка:

тогда пользовательское действие будет выполняться при загрузке сборки:

Если целевым действием для пользовательского действия является Suite, пользовательское действие выполняется до и после всех тестов осветителей, ведя себя как «до или после всех наборов». Однако обратите внимание, что если указан TargetActions.Test, то действие выполняется до или после всех тестов во всех пакетах. Поэтому следует соблюдать осторожность в отношении возвращаемого значения свойства Target и желаемого поведения определенного пользователем действия.

Передача информации в / из тестов из пользовательских действий

Два вопроса могут быть:

Передача информации в пользовательское действие

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

и применяя его к светильнику:

приводит к следующему потоку испытаний:

Обратите внимание, что пользовательское действие для набора выполняется после настройки «пространства имен» и после настройки прибора. Если для определенного пользователем действия требуется некоторая информация, которую нельзя передать с помощью конструктора (конструкторы атрибутов ограничены константами), то может оказаться полезным подход, аналогичный описанному ниже. Однако имейте в виду, что определяемые пользователем действия должны быть как можно более автономными — следует избегать перепутывания с тестовыми состояниями.

Передача информации из пользовательского действия в Test / Test Suite

Это невозможно без какой-либо формы пограничного контейнера. Чрезвычайно простая реализация — создать пакет объектов из словаря значения ключа:

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

Данные могут быть доступны в тестовых методах:

Существуют более сложные подходы, и предыдущие примеры предназначены для иллюстрации того, как координировать пользовательское действие с обменом информацией. В предыдущем примере есть множество проблем — безопасность типов, отсутствие проверок того, существует ли объект в контейнере и т. Д. — проблемы, которые должен обрабатывать надежный класс контейнера.

NUnit Основные утверждения

NUnit предоставляет те же или похожие утверждения в классе NUnit.Framework.Assert, что и в классе Assert в Visual Studio, как описано ранее. NUnit также предоставляет дополнительные утверждения:

IsEmpty / IsNotEmpty

Эти утверждения проверяют, является ли строка пустой или нет, или что коллекция пуста или нет:

Больше / Меньше

Эти два утверждения работают с числовыми значениями и объектами, реализующими IComparable, утверждая, что первое значение больше или меньше второго значения. Цель этого утверждения — улучшить читаемость теста.

GreaterOrEqual / LessOrEqual

Эти два утверждения работают с числовыми значениями и объектами, реализующими IComparable, утверждая, что первое значение «больше или равно» или «меньше или равно» второму значению. Цель этого утверждения — улучшить читаемость теста.

IsAssignableFrom / IsNotAssignableFrom

Эта пара методов утверждает, что ожидаемый тип можно назначить из экземпляра объекта совместимого типа. Это похоже на утверждение IsInstanceOfType в тестовом движке Visual Studio. Например, учитывая:

Этот тест проходит, потому что объекту типа A может быть присвоен экземпляр типа B.

Выдает / Выдает / DoesNotThrow

Неуниверсальная форма этого утверждения подтверждает, что исключение выдается (или нет) при вызове указанного метода. Например:

Этот тест проходит.

Универсальная версия помещает тип исключения в качестве универсального параметра:

Стопор / улов

Эти два метода утверждают, что метод генерирует тип исключения или один из его производных. Напротив, метод Throws до этого утверждает, что выбрасывается именно указанный тип исключения. Например, этот код передает:

Сборник утверждений

В классе NUnit.Framework.CollectionAssert NUnit реализует те же утверждения, что и в классе CollectionAssert Visual Studio, с этими дополнительными утверждениями:

Обратите внимание, что параметр коллекции в этих методах предполагает, что коллекция будет реализовывать IEnumerable (в отличие от тестовой среды Visual Studio, которая ожидает ICollection).

IsEmpty / IsNotEmpty

Метод CollectionAssert.IsEmpty такой же, как метод Assert.IsEmpty.

IsOrdered

Этот метод проверяет, что значения в коллекции упорядочены. Например, потому что AnObject реализует IComparable:

этот тест проходит:

Строковые утверждения

Эти методы утверждения являются членами класса NUnit.Framework.StringAssert и такие же, как и в классе StringAssert в Visual Studio, с несколькими отличиями:

которые обсуждаются далее.

AreEqualIgnoringCase

Утверждение «AreEqualIgnoringCase» выполняет сравнение двух строк, игнорируя регистр.

IsMatch

Этот метод похож на метод StringAssert.Matches в Visual Studio — он утверждает, что строка соответствует шаблону регулярного выражения.

Утверждения файла

Эти методы утверждения являются членами класса NUnit.Framework.FileAssert.

AreEqual / AreNotEqual

Эти методы утверждают, что два файла идентичны или нет. Побайтовое сравнение выполняется для двух файлов. Если файлы пусты, они считаются равными. Если один или оба файла не существуют, выдается исключение FileNotFoundException.

Утверждения каталога

Эти методы утверждения являются членами класса NUnit.Framework.DirectoryAssert.

AreEqual / AreNotEqual

Эти методы утверждают, что файлы в двух каталогах одинаковы или нет.

IsEmpty / IsNotEmpty

Эти методы утверждают, что каталог пуст или нет.

IsWithin / IsNotWithin

Эти методы утверждают, что путь содержит указанный подкаталог или нет.

Другие утверждения

В то время как одна из форм этого метода принимает булевский параметр в качестве подтверждения истины (ведет себя точно так же, как Assert.IsTrue), преобладающей формой этого метода является возможность сравнивать фактическое значение с использованием определенного ограничения. Документация NUnit по ограничениям довольно обширна в отношении ограничений, поэтому здесь будет приведен только краткий пример. Например, учитывая этот тест:

Используя систему ограничений, утверждение может быть переписано как:

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

IsNaN

Этот метод проверяет, является ли двойное значение «не числом». Типичным случаем, когда значение не является числом, является деление на ноль или квадратный корень из отрицательного значения.

Полезные методы

Класс assert также предоставляет несколько служебных методов:

Источник