JUnit's @Ignore

Question

Интересно, будет ли хорошей практикой использование @Ignore JUnit. И как люди этим пользуются?

Я придумал следующий вариант использования: допустим, я разрабатываю класс и пишу для него тест JUnit, который не проходит, потому что я еще не закончил с классом. Это хорошая практика, чтобы пометить его как @Ignore?

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

Answer 1

Полагаю, все в порядке.

документы говорят,

Участники тестирования сообщат о количестве пропущенных тестов, а также о количестве тестов. и количество пройденных тестов.

Следовательно, это означает, что даже если вы забудете удалить это впоследствии, вы должны быть уведомлены об этом.

Пример, приведенный в документах , полностью напоминает ваш случай.

@Ignore("not ready yet")

Answer 2

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

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

Answer 3

ИМХО, не обращайте внимания, что не следует использовать слегка ... из-за эффекта разбитых окон.

Я редко использую этот атрибут / аннотацию в xUnit. Я только несколько раз использовал их как TODO при написании TestCase # 1, я вижу еще один тестовый пример, который я пропустил, но который также должен быть включен. Чтобы я не забыл об этом, я пишу небольшой тестовый пример с описательным именем и помечаю его как Ignore. Приступить к завершению TestCase # 1. Но это все внутри-регистрация. Я никогда не проверяю тесты, помеченные как Ignore.

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

Другие «особые случаи», о которых я могу думать, это ..
Когда вы ожидаете компонент от другой команды / сотрудника / поставщика (чей интерфейс был опубликован и согласован), без которого тесты не могут быть запущены. В этом случае вы можете написать тесты и пометить их как Ignore («Ожидание X, чтобы доставить компонент Y»)

Answer 4

Я думаю, что это очень хороший способ использовать его.

Ваш CI-сервер должен быть всегда зеленым (или синим в случае Хадсона). Всякий раз, когда это не ваш первый приоритет, это исправить.

Теперь, если CI сломался из-за ошибки в тестовом коде (возможно, тестовый код является непослушным и недетерминированным), вам следует просто проигнорировать тест "@Ignore (Этот тестовый код является borken, поднял дефект # 123) "и поднять ошибку в вашем трекере дефектов.

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

Я надеюсь, что форматер отчетов junit xml, используемый при запуске тестов из ant, однажды будет включать в себя игнорируемое количество (и причины) наряду с pass, fail и error. Может быть, тогда поставщики CI будут включать игнорируемые результаты тестов (если нет, возможно, мне придется написать плагин Hudson ...)

Answer 5

Ну, если вы еще не закончили с классом, это хорошо, тест не пройден. Пометка @Ignore будет означать, что вы отправите код с незавершенным классом. И верно, может быть, вы еще не используете этот класс в каком-либо выполняемом коде, но когда-нибудь другой разработчик может увидеть этот класс и использовать его. Тогда он терпит неудачу, даже это должно работать.

Я бы точно не использовал @Ignore в этом случае.

Answer 6

Я думаю, что использование @ignore в порядке, пока есть -

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

Это правила, по крайней мере, на мой взгляд; -)

Answer 7

@Ignore может использоваться в тестах, написанных для некоторых сторонних сервисов. Недавно я обнаружил, что мне нужно проверить, отправляет ли внешняя служба данные, которые я ожидаю. Это было очень удобно делать в тесте (издевается). Поскольку я знал , что мои входные данные не будут работать вечно, и мне, возможно, потребуется запустить аналогичный тест позже, я добавил @Ignore вместо удаления теста.

Answer 8

Я думаю, что можно использовать @ Ignore's, когда тест основан на внешних объектах, которые нельзя смоделировать. Нам все еще нужен тест, чтобы убедиться, что все работает, но мы не хотим развертывать тест, основанный на внешней зависимости.

Например, если вы пишете пользовательский SpreadsheetWriter / Reader для документов Google, имеет смысл использовать настоящий документ Google для его тестирования. Однако вы не захотите, чтобы ваша сборка потерпела неудачу, если документы Google не работают по любой причине. После подтверждения того, что ваш модульный тест проходит локально, я бы добавил @Ignore, прежде чем запускать его в производство.

В общем, я думаю, что @Ignore следует избегать, насколько это возможно, потому что в большинстве случаев внешние классы / системы могут быть поддельными.

Answer 9

Я думаю, что это идет вразрез с основными принципами разработки, управляемой тестами. Конечно, если вы не занимаетесь TDD, это, вероятно, не имеет большого значения.

Я бы сказал, что если вы используете @ignore, значит, вы не LEAN и не используете TDD.

Если вы работаете с TDD, вам никогда не придется проваливать тесты в любом коммите, который вы делаете в своем репо.

Я полностью сумасшедший или это имеет смысл?