@Ignore JUNIT

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

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

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

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

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

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

Я думаю с помощью @ignore, в порядке, пока существует -

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

Это - правила, по крайней мере, в моем уме;-)

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

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

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

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

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

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

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

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

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