Skip to content

Latest commit

 

History

History

multiple_asserts

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 

Методы содержат несколько ассертов

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

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

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

Проблемы

Плохая читаемость кода - его слишком много.

Если тест прервётся в середине, следующие утверждения не будут проверены.

Название теста будет вынужденно слишком общим.

Теория

В тестах можно выделить три части проверки:

  • настройка окружения,
  • выполнение действия,
  • проверка постусловий.

Что делать

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

  2. Сложное условие стоит вынести в утилитный метод с говорящим названием, либо в Matcher.

    Если надо проверить сложный объект, то можно сравнивать возвращённое значение с референсным объектом.

  3. Использовать Assume вместо Assert для проверки про��ежуточных состояний по ходу теста

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