Как я игнорирую тест на основе другого теста в NUnit?

Тесты никогда не должны зависеть друг от друга. Вы только что узнали почему. Тесты, которые зависят друг от друга, по определению хрупки. Если вам нужны данные в БД для теста Get () , поместите их туда на этапе настройки.

Я не думаю, что это возможно из коробки.

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

MbUnit , похоже, имеет DependsOnAttribute , который позволит вам делать то, что вы хотите.

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

Хотя ничего не знаю о NUnit.

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

По сути, вы хотите, чтобы AddTest запускался перед GetTest , и вы хотите, чтобы NUnit прекратил выполнение тестов в случае сбоя AddTest.

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

Стандартная концепция модульного тестирования заключается в том, что Если у вас есть тест на функциональность «Добавить», то вы можете использовать функциональность «Добавить» в тесте «Получить» и не беспокоиться о том, работает ли «Добавить» в тесте «Получить». Вы знаете, что «Добавить» работает - у вас есть проверка.

Принцип «ПЕРВЫЙ» ( http://agileinaflash.blogspot.com/2009/02/first. html ) описывает, как должны вести себя модульные тесты. Тест, который вы хотите написать, нарушает как «I» (изолированный), так и «R» (повторяемый).

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

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

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

Создайте глобальную переменную и верните в тесте для Get , если Добавить не установит для нее значение true (сделайте это в последней строке Добавьте ):

public boolean addFailed = false;
public void testAdd () {
    try {
        ... old test code ...
    } catch (Throwable t) { // Catch all errors
        addFailed = true;
        throw t; // Don't forget to rethrow
    }
}
public void testGet () {
    if (addFailed) return;
    ... old test code ...
}

NUnit поддерживает синтаксис « Assume.That » для проверки настройки. Это задокументировано как часть теории (спасибо clairestreb ). В пространстве имен NUnit.Framework есть класс Предположим . Процитирую документацию:

/// Provides static methods to express the assumptions
/// that must be met for a test to give a meaningful
/// result. If an assumption is not met, the test
/// should produce an inconclusive result.

Итак, в контексте:

public void TestGet() {
    MyList sut = new MyList()
    Object expecting = new Object();
    sut.Put(expecting);
    Assume.That(sut.size(), Is(1));
    Assert.That(sut.Get(), Is(expecting));
}