Единичное тестирование. Правильно ли иметь утверждения в методах настройки?

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

В этих методах настройки мне нравится использовать утверждения: я знаю, какие значения я хочу видеть в тех объектов, и мне нравится документировать это знание через утверждение.

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

Но нет никакой разницы в "настройках с утверждениями" и unit test вызывает другие модульные тесты.

Следовательно, мой вопрос: есть ли хорошая практика иметь утверждения в методах настройки?

EDIT:

Ответ оказывается: это не хорошая практика в целом. Если результаты установки необходимо протестировать, рекомендуется добавить отдельный тестовый метод с утверждениями (ответ, который я отметил); для документирования намерений, рассмотрите использование утверждений Java.

Ответ 1

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

Я видел несколько преимуществ:

Настройка для краткости и фокусировки для удобства чтения.
Утверждения запускаются только один раз, что более эффективно.

Использование и обсуждение:

Например, я называю метод testSetup().

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

Если кому-то это мешает и хочет сделать эту зависимость явной, testSetup() можно вызвать в методе setup(). Но я не думаю, что это важно. Я хочу сказать, что в JUnit вы можете уже иметь что-то подобное в остальных тестах:

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

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

Ответ 2

Это разные сценарии; Я не вижу сходства.

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

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

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

Ответ 3

Наличие утверждений в методах Setup/TearDown не рекомендуется. Это делает тест менее понятным, если пользователь должен "понять", что некоторые из тестовых логических схем не находятся в методе тестирования. Бывают случаи, когда у вас нет выбора, кроме как использовать методы настройки/разборки для чего-то другого, кроме того, для чего они предназначены.

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

Ответ 4

Следуйте за своим сердцем/принимайте решения. Утверждения в методе установки могут документировать намерение; улучшенная читаемость. Поэтому я лично поддержал бы вас. Это отличается от теста, вызывающего другие тесты - что плохо. Нет тестовой изоляции. Тест не должен влиять на результат другого теста.

Хотя это не случай использования freq, я иногда использую Asserts внутри метода установки, чтобы я мог знать, не была ли тестовая настройка, как я предполагал; обычно, когда я имею дело с компонентами, которые я сам не писал. Ошибка подтверждения, которая гласит: "Ошибка установки"! на вкладке "Ошибки" - быстро помогает мне войти в код установки вместо того, чтобы смотреть на кучу неудачных тестов.

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

Ответ 5

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

byte[] pkt = pktFactory.makePacket(TIME, 12, "23, F2");
assert pkt.length == 15;

Неудачная система подразумевает, что система не в состоянии даже попытаться запустить этот тест.