@Ignore от JUnit

Полагаю, это неплохо.

документы говорит:

Test runners will report the number of ignored tests, along with the number of tests that ran and the number of tests that failed.

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

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

@Ignore("not ready yet")

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

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

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

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

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

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

Я редко использую этот атрибут / аннотацию в xUnit. Я использовал их только несколько раз в качестве ДЕЛАТЬ при написании TestCase # 1, я вижу еще один тестовый пример, который я пропустил, но который также должен быть включен. Чтобы не забыть, я пишу небольшой тестовый пример с описательным именем и помечаю его как «Игнорировать». Приступите к заполнению TestCase # 1. Но это все внутри регистрации. Я никогда не проверяю тесты с пометкой "Игнорировать"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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