Тесты в зависимости от часто используемых функций с NUnit - PullRequest
5 голосов
/ 03 августа 2010

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

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

В идеале мне бы хотелось, чтобы это было поведение:

  1. Выполнен тест инициализации.
  2. Другие тесты запускаются при успешном выполнении [1].

Во всех случаях, когда [1] не удастся, так же как и во всех других тестах. Но ценная информация заключается в том, что [1] не удается. Вот где я, скорее всего, найду проблему. Было бы хорошо, если бы другие тесты могли быть отмечены? или что-то, что указывает на то, что они не выполнялись, поскольку функциональность, от которой они зависят, не прошла тесты.

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

Это более общая проблема, когда некоторые функции зависят от других функций. Где «другая функциональность» слишком часто используется, чтобы предоставить какую-либо реальную ценность, провалив все тесты в зависимости от нее. Было бы лучше, если бы «другие функциональные возможности» проверялись отдельно.

Ответы [ 4 ]

2 голосов
/ 03 августа 2010

Хорошо, вот как бы я поступил об этом ...

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

  • все тесты в наборе провалились (что я научил со временем распознавать как подсказку, что, возможно, установка / демонтаж вызвала исключение).
  • трассировка стека для неудачных тестов, содержащих метод Setup.

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

[Test]
public void VerifySetup() {}

Обновление: похоже, у вас есть довольно нишевое требование. Я не знаю ни одного механизма в NUnit для определения такого условного выполнения тестов - например, Запускайте Test2 - 10 только в случае прохождения Test1.

1 голос
/ 04 августа 2010

Я общался с разработчиками NUnit.В настоящее время это невозможно без написания довольно сложного плагина.Функция появится где-то в базе кода 3.x, но не появится в 2.5.Я подумаю над тем, чтобы написать его, но не сейчас.

0 голосов
/ 03 августа 2010

Я думаю, что это довольно ясно.Проблема в том, что вам трудно разделить обязанности API.У вас есть два.Инициализация API и выполнение API.Написание ваших тестов с такой зависимостью может убить вас.

Поэтому я бы порекомендовал API создать объект инициализации, а затем различные объекты команд для выполнения API.Командные объекты будут в каком-то хранилище, или вы можете создать их на лету.

API будет использовать фиктивный объект инициализации и будут использовать фиктивные командные объекты.

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

Объектам Command потребуется поддельный объект инициализации.

[EDIT]

Есть два способа заставить другие тесты завершиться неудачей, если тест инициализации не пройден

  1. Добавить частную переменную в тестовый пример.private isInitialized = false;.Затем все остальные ваши тесты проверяют состояние этой переменной, если не true, а затем завершаются неудачей.

  2. Расширьте свой контрольный пример с помощью класса API.Добавьте частную функцию, которая запрашивает состояние инициализации.

Очиститель двух - 2. Самая быстрая реализация - 1.

IMHO Это можетбыть запахом кода, когда вы должны соединить свои тесты таким образом.Если, как вы сказали, это интеграционные тесты.Почему у вас есть отдельный тест для инициализации.Интеграция больше похожа на выполнение некоторых действий против вашего API.Поэтому каждый интеграционный тест ДОЛЖЕН инициализировать API.

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

[EDIT1a]

Единственный способ убедиться, что вы удовлетворяете вашим требованиям, - это продлить NUnit .В частности, обратите внимание на Конструкторы тестовых наборов и Декораторы тестов .

Ссылка датирована мартом 2008 года, так что, надеюсь, она не устарела.

0 голосов
/ 03 августа 2010

Попробуйте это:

  1. Определить "Тест инициализации" как TestCase

  2. Сделайте все остальные ваши тесты подклассом этого TestCase

  3. Создайте пакет, который запускает ваши тесты в определенном порядке, чтобы ваш «тест инициализации» был первым.

...