Модульное тестирование без утверждений

Question

Иногда я сталкиваюсь с юнит-тестом, который ничего не утверждает. Конкретным примером, с которым я столкнулся сегодня утром, было тестирование записи файла журнала при выполнении условия. Предполагалось, что если не было выдано никакой ошибки, тест пройден.

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

Просто интересно, как люди к этому относятся?

Answer 1

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

Answer 2

Это был бы официальный способ сделать это:

// Act
Exception ex = Record.Exception(() => someCode());

// Assert
Assert.Null(ex);

Answer 3

Если нет подтверждения, это не тест.

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

Answer 4

Они известны как тесты на дым и распространены. Это основные проверки вменяемости. Но они не должны быть единственными видами испытаний, которые у вас есть. Вам все еще нужна какая-то проверка в другом тесте.

Answer 5

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

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

Если у вас есть явное требование, чтобы тестируемый код не выдавал исключение, и вы хотите явно указать этот факт (тестирование как документация по требованиям), тогда я бы сделал что-то вроде этого:

try
{
  unitUnderTest.DoWork()
}
catch
{
  Assert.Fail("code should never throw exceptions but failed with ...")
}

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

Answer 6

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

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

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

Answer 7

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

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

РЕДАКТИРОВАТЬ: В примере, приведенном OP, есть некоторый тестируемый результат (результат файла журнала), поэтому предполагается, что, если не было сгенерировано никакой ошибки, это сработало, лениво.

Answer 8

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

Answer 9

Название теста должно документировать это.

void TestLogDoesNotThrowException(void) {
    log("blah blah");
}

Как тест проверяет, записывается ли журнал без подтверждения?

Answer 10

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