В JUnit @игнорировать полезность?

в JUnit вы можете использовать @Ignore перед методами, чтобы сказать бегуну теста автоматически пропустить эти тесты. Из того, что я могу собрать, это действительно только удобный способ документировать/отмечать неполные/больше не функциональные тесты, к которым вы хотите вернуться позже.

правильно ли я говорю, что во время выполнения нет разницы между тестом @Ignore, методом без аннотации и прокомментированным методом? (Предполагая, что все эти тесты самодостаточны.) Есть какой-то способ получить список игнорируемых тестовых случаев в JUnit на Netbeans? Если нет, то насколько полезен тег @Ignore, так как было бы полезнее провалить тест, чтобы его не упустить?

6 ответов


правильно ли я говорю, что во время выполнения нет разницы между тестом @Ignore, методом без аннотации и прокомментированным методом?

An @Ignoreметод d можно найти через отражение. Метод без аннотации не может (или, если быть точным, он не может быть выявлен С уверенностью как игнорируемый метод тестирования), а прокомментированный метод даже не попадает в байт-код.

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

сколько полезности имеет тег @Ignore

одна вещь, о которой я могу думать, - это поиск. Вы можете легко идентифицировать все @Ignore аннотации в исходном коде, в то время как необъявленные или закомментированные тесты не так просто найти.

это может быть более полезным, чтобы провалить тест, так что это не проглядел?

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


  • метод без аннотации, скорее всего, является полезным методом, вероятно, используемым другими методами в тесте.

  • прокомментированный метод-это тот, который полностью скрыт.

  • но вы можете использовать @Ignore, чтобы указать, что вы временно отключить проверку. Если у вас есть большой и сложный фрагмент кода, который находится в процессе перехода, вы можете временно отключить некоторые тесты, пока этот код не работает, особенно если механизм, выполняющий этот код, выполняется как часть некоторого большего набора регрессий. The @Ignore атрибут будет напоминанием вам (или вашей команде QA), что еще многое нужно сделать.

    помните, что @Ignore'D тесты по-прежнему живой код, и могут быть замечены и даже выполнены через отражение, которое закомментированный код не может быть. И это также означает, что при рефакторинге кода на другой код, они также обновляются и ломкость синтаксис в API там покажет. Так что даже тесты с @Ignore set может активно способствуют качеству кода.

  • JUnit 4 TestRunners покажет @Ignore'D тесты как "пропущенные", так что вы можете увидеть, в конце концов, сколько тестов прошло/не удалось/пропущено.

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


@Ignored тесты более ремонтопригодны (и поддерживаются), чем закомментированные. Они подвержены ошибкам компилятора по мере развития, структурированного поиска с помощью IDE и рефакторинга с помощью IDE.


кстати, TestNG поддерживает это немного по-другому:

  • вы можете включить описание того, почему тест игнорируется:

    @Test(enabled = false, description = "Disabled until BUG-1234 gets fixed")
    
    • плагин Eclipse TestNG и отчеты HTML будут дать вам список всех тестов, которые были отключены вместе с причина:

enter image description here


используя @Ignore вместо комментария @Test имеет то преимущество, что Hudson/Jenkins распознает это как игнорируемый тест и отображает его в результатах теста соответственно. Таким образом, вам напоминают об этом проигнорированном тесте, который является большим преимуществом!


IMHO, @Ignore полезность будет знать в отчетах, что есть X пропущенных тестов, которые вы не получите, если тест не аннотируется как тест или комментируется. Провал тестов не является хорошим вариантом, поскольку мы знаем, что тесты, которые мы хотим игнорировать, в какой-то момент не актуальны, но должны быть повторно включены позже. Поэтому мы хотим увидеть, будут ли все другие тесты успешными/ неудачными, зная, что мы пропустим не относящиеся к делу (тот факт ,что мы пропустили их, будет виден в подотчетный.)