Интересно, стоит ли использовать JUnit @Ignore. И как люди его используют?
Я пришел к следующему варианту использования: скажем, я разрабатываю класс и пишу для него тест JUnit, который не проходит, потому что я не совсем поступил с классом. Хорошая практика отметить его с помощью @Ignore?
Я немного обеспокоен тем, что позже мы можем пропустить проигнорированный тестовый пример или что люди начинают использовать его для "принудительных" тестов для прохождения CI.
Это очень хорошо, я полагаю.
docs говорит,
Тестеры покажут количество проигнорированных тестов, а также количество тестов который запущен, и количество неудачных тестов.
Следовательно, это означает, что даже если вы забыли удалить это, вы должны были быть уведомлены об этом.
Пример, приведенный в docs, полностью напоминает ваш случай.
@Ignore("not ready yet")
Я регулярно использую @Ignore для тестов, которые терпят неудачу из-за известной ошибки. Как только ошибка подтверждается и регистрируется в базах данных ошибок, сбой теста не имеет смысла, поскольку ошибка уже известна.
Тем не менее, имеет смысл сохранить тестовый код, потому что он будет полезен снова после исправления ошибки. Поэтому я отмечаю, что это игнорируется, с комментарием, указывающим на связанную ошибку, и в идеале отмечаем в отчете об ошибке, что тест должен быть реактивирован для проверки исправления.
ИМХО, Игнорировать, что не следует использовать легко... из-за эффекта разбитых окон.
Я редко использую этот атрибут/аннотацию в xUnit. Только несколько раз я использовал их как TODO при написании TestCase # 1, я вижу еще один тестовый пример (я), который я пропустил, но который также должен быть включен. Просто чтобы я этого не забыл, я пишу небольшой тестовый пример с описательным именем и отмечаю его с помощью Ignore. Перейти к завершению TestCase # 1. Но это все внутри-регистрация. Я никогда не проверяю тесты, отмеченные знаком "Игнорировать".
Однако обычно я просто использую лист бумаги - тестовый список, чтобы записать новый тестовый пример - это намного проще. Это также подходит для сценария, где я частично завершен... завершено 5 из 10 тестов. Вместо проверки в 5 Игнорируемых тестах я бы сохранил тестовый список и проверил 5 проходящих тестов. Предполагается, что вы закончите остаток в следующих нескольких заездах, прежде чем переходить на что-то новое.
Другие "особые случаи", о которых я могу думать, - это... Когда вы ожидаете компонент от другой команды/лица/поставщика (интерфейс которого был опубликован - согласован), без которого тесты не могут выполняться. В этом случае вы можете написать тесты и пометить их с помощью Ignore ( "Ожидание X для доставки компонента Y" )
Я думаю, что это отличный способ использовать его.
Ваш сервер CI должен быть зеленым (или синим в корпусе Хадсона) все время. Всякий раз, когда это не ваш первый приоритет, это исправить его.
Теперь, если CI сломался из-за ошибки в тестовом коде (возможно, тестовый код непослушен и не детерминирован), вы должны просто проигнорировать тест "@Ignore (этот тестовый код - borken, повышенный дефект № 123)" и поднимите ошибку в вашем трекер-дефекторе.
Вы не будете отправлять сломанный код, потому что всякий раз, когда вы отправляете товар, вы просматриваете все дефекты и решаете, есть ли у них какие-либо пробковые пробки? Сломанный тест, который не работает, будет рассмотрен вместе с тестируемым кодом/функцией. Вы отправляете, если и только если вы счастливы, что код, который он тестировал, также не нарушен. Если он не протестирован, считайте его сломанным.
Я надеюсь, что форматировщик junit xml report, используемый при выполнении тестов из ant, в один прекрасный день включит игнорируемый счет (и причины) вместе с пропуском, сбоем и ошибкой. Возможно, тогда поставщики CI будут включать в себя игнорируемые контрольные подсчеты (если нет, мне, возможно, придется написать плагин Hudson...)
Хорошо, если вы не закончили с классом, это хорошо, тест не проходит. Пометить его как @Ignore означает, что вы отправите код с незавершенным классом. И правильно, может быть, вы еще не используете этот класс в любом коде, который выполняется, но когда-нибудь какой-нибудь другой разработчик может увидеть этот класс и использовать его. Тогда он терпит неудачу, даже он должен работать.
Я бы не использовал @Ignore в этом случае наверняка.
Я думаю, что использование @ignore в порядке, пока есть -
Это правила, по крайней мере, в моем уме; -)
Я думаю, что это идет вразрез с основными принципами разработки, основанной на тестах. Если вы не делаете TDD, то это, вероятно, не имеет значения.
Я бы сказал, что если вы используете @ignore, тогда вы не LEAN и не делаете TDD.
Если вы делаете TDD, вы никогда не должны испытывать сбоев в любой фиксации, которую вы делаете в своем репо.
Я совершенно сумасшедший или это имеет смысл?
Я думаю, что использовать @Ignore, когда тест полагается на внешние объекты, которые не могут насмехаться. Нам все еще нужен тест, чтобы убедиться, что все работает, но мы не хотим развертывать тест, который зависит от внешней зависимости.
Например, если вы пишете пользовательский документ SpreadsheetWriter/Reader для Google, имеет смысл использовать настоящий документ google для его проверки. Однако вы не хотите, чтобы ваша сборка завершилась неудачей, если google docs отключены по какой-либо причине. Убедившись, что ваш unit test проходит локально, я бы добавил @Ignore, прежде чем нажимать его на производство.
В общем, я думаю, что @Ignore следует избегать как можно больше, потому что в большинстве случаев внешние классы/системы можно издеваться.
@Ignore может использоваться для тестов, написанных для некоторых сторонних служб. Недавно я обнаружил, что мне нужно проверить, отправляет ли внешняя служба обратно данные, которые я ожидаю. Это было очень удобно делать в тесте (mocks). Поскольку я знал, что мои входные данные не будут работать вечно, и мне, возможно, придется запустить аналогичный тест позже, я добавил @Ignore вместо удаления теста.