Могут ли модульные / интеграционные тесты не утверждать?А как насчет этого конкретного случая?

Question

Сценарий: у меня есть несколько интеграционных тестов. Один из них тестирует удаление. Итак, я сделал:

@Test
@Order(6)
public void delete() {
    rfxCriteriRepository.delete(rfxCriteriEconomico.getIdrfxcriteri());
}

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

@Test
@Order(7)
public void getDelete() {
    RfxCriteri rfxCriteriEconomicoDb = rfxCriteriRepository.findByIdrfxcriteri(
        rfxCriteriEconomico.getIdrfxcriteri()
    );

    Assertions.assertNull(rfxCriteriEconomicoDb);
}

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

Как вы думаете, каждый тест должен иметь assert? Или вы думаете, что эти два теста должны быть уникальными? Может кто-нибудь подсказать мне какое-нибудь руководство по модульному тестированию, которое что-то говорит об этом?

Answer 1

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

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

1. Один случай, когда сумма двух сторон длины чуть выше (на эпсилон) длины третьей стороны: a + epsilon == b + c - это будет действительный треугольник в любом случае.
2. Один случай, когда одна сторона длиннее (снова на эпсилон), чем сумма двух других, например a - epsilon == b + c. Это должно вызвать исключение, поскольку это недопустимый треугольник.
3. Наконец ситуация, когда a == b + c.

Предположим, что в вашем коде ситуация в случае 3 приведет к вырожденному, но действительному треугольнику. Тогда может иметь смысл иметь контрольный пример, который не делает ничего больше, чем просто создает этот треугольник - чтобы увидеть, что не выдается исключение. Помните, что ваши тесты также могут рассматриваться как документирование вашего кода: такой тест прекрасно документирует, что ваш код позволяет создавать такие треугольники. Тестовый пример в этом случае обязательно должен быть реализован и назван так, чтобы намерение стало ясным, например, «constructing_aDegenerateTriangle_shallSucceedWithoutExceptionRaised».

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

Answer 2

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

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

Написание «тестов», которые успешно выполняются, потому что в коде нет ошибок, бессмысленновы на самом деле ничего не тестируете, существует множество способов написания кода, который не дает ошибок, но на самом деле ничего не делает.

тестирует крайние случаи - вы передаете 0 как id, вы передаете ноль.проверить, что происходит, когда идентификатор не существует в БД.Проверьте, что происходит, когда идентификатор существует, но есть связанные данные, что, вероятно, означает, что вам нужно сначала удалить другие вещи.протестируйте сценарий «счастливого пути».

, если вы ожидаете определенных ошибок в определенных сценариях, проверьте их также.

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