Огурец - Как отметить ожидаемые неудачи, как известные проблемы?

Question

Я успешно использую Cucumber для обработки моих тестов на основе Java.

Иногда эти тесты сталкиваются с проблемами регрессии, и для исправления обнаруженных проблем требуется время (в зависимости от приоритета вопроса, это может быть недели или даже месяцы). Итак, я ищу способ отметить некоторые тесты огурца, как известные проблемы. Не хотите, чтобы эти тесты не прошли весь набор тестов, просто отметьте их, например, как ожидающие желтого цвета в отчете.

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

Некоторые другие структуры обеспечивают такую ​​функциональность (запустите тест, но проигнорируйте его результат в случае сбоя). Можно ли сделать один и тот же трюк, используя Cucumber?

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

Любые идеи оценили. Заранее спасибо.

Answer 1

Я бы предпочел выбросить ожидающее исключение на шаг, который вызывает известный сбой. Это позволит выполнить шаг и не забывать.

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

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

Answer 2

Вы не должны.

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

Если у вас есть сценарии, которые не работают из-за ошибки, тогда отчет должен показать, что если сценарий не полностью реализован, лучше не запускать его вообще.

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

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

Я думаю, что клиент будет лучше понимать, если эти сценарии являются красными, потому что они терпят неудачу, а не какой-то желтый цвет с «серым» статусом того, что происходит.

Если вам нужен статус запуска для запуска некоторого задания CI, возможно, лучше изменить его состояние.

Как я вижу, то, что вам нужно, чтобы дать ему мысли, должно быть: в чем разница между желтым или красным, ожидающим или неспособным для вас или клиента ?, вы бы палочкой, чтобы иметь четкую разницу и отслеживать реальный статус.

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