Как вы справляетесь с модульными / регрессионными тестами, которые, как ожидается, не пройдут во время разработки?

Question

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

В наших командах ведутся постоянные споры о том, как проводить неудачные тесты:

1. Закомментируйте неудачные тестовые случаи с комментарием REVISIT или TODO.

   • Преимущество : Мы всегда будем знать, когда был введен новый дефект, а не тот, о котором мы уже знаем.
   • Недостаток : Может забыть ПЕРЕСМОТРЕТЬ закомментированный контрольный пример, означающий, что дефект может проскользнуть сквозь трещины.

2. Оставить тесты неудачными.

   • Преимущество : не забудем исправить дефекты, так как ошибки скрипта будут постоянно напоминать вам о наличии дефекта.
   • Недостаток : Сложно обнаружить при появлении нового дефекта из-за шума отказа.

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

• Процент пройден: 75%
• Процент неудачных (ожидаемых): 20%
• Процент сбоя (неожиданно): 5%

В целом вы должны пометить любые тестовые случаи, которые, как вы ожидаете, потерпят неудачу (из-за некоторого дефекта) с некоторыми метаданными. Это гарантирует, что вы все равно увидите результат сбоя в конце теста, но сразу же узнаете, есть ли сбой new , которого вы не ожидали. Это, кажется, берет лучшие части 2 предложений выше.

У кого-нибудь есть лучшие практики для управления этим?

Answer 1

Я бы оставил ваши тесты внутри. По моему опыту, комментируя код с чем-то вроде

// TODO:  fix test case

сродни делать:

// HAHA: you'll never revisit me

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

Оставьте тесты, возможно, с вашим решением "три состояния". Тем не менее, я бы настоятельно рекомендовал исправить эти случаи как можно скорее. Моя проблема с постоянными напоминаниями состоит в том, что после того, как люди видят их, они склонны замазывать их и говорить: «О да, мы постоянно получаем эти ошибки ...»

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

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

Answer 2

Исправьте ошибку сразу.

Если это слишком сложно сделать сразу, вероятно, это слишком большая единица для модульного тестирования.

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

Answer 3

Я обычно работаю в Perl, и модули Perl Test :: * позволяют вставлять блоки TODO:

TODO: {
  local $TODO = "This has not been implemented yet."

  # Tests expected to fail go here
}

В подробном выводе о выполнении теста сообщение в $ TODO добавляется к отчету о прохождении / неудаче для каждого теста в блоке TODO, чтобы объяснить, почему ожидалось, что оно не выполнится. Для суммирования результатов тестов все тесты TODO считаются успешными, но, если они действительно возвращают успешный результат, сводка также подсчитывает их и сообщает количество тестов, которые неожиданно прошли успешно.

Тогда я рекомендую найти инструмент тестирования, который имеет аналогичные возможности. (Или просто используйте Perl для тестирования, даже если тестируемый код написан на другом языке ...)

Answer 4

Мы сделали следующее: поставили иерархию на тесты.

Пример: вам нужно проверить 3 вещи.

• Проверка входа в систему (вход в систему, получение имени пользователя, получение «последней даты входа» или что-то знакомое и т. Д.)
• Проверка поиска в базе данных (поиск по заданному тегу "schnitzelmitkartoffelsalat", поиск по последним тегам)
• Тестирование веб-сервисов (подключение, получение номера версии, получение простых данных, получение подробных данных, изменение данных)

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

3. Connect to a web service
    ...
3.1. Get the version number
    ...
3.2. Data:
    3.2.1. Get the version number
    3.2.2. Retrieve simple data
    3.2.3. Retrieve detailed data
    3.2.4. Change data

Если точка не работает (при разработке) , дать одно точное сообщение об ошибке . То есть 3.2.2. не удалось. Тогда блок тестирования не будет выполнять тесты для 3.2.3. и 3.2.4. , Таким образом, вы получите одно (точное) сообщение об ошибке: «3.2.2 fail». Таким образом, оставив программиста решить эту проблему (сначала), а не обрабатывать 3.2.3. и 3.2.4. потому что это не сработает.

Это очень помогло прояснить проблему и прояснить, что нужно сделать вначале.

Answer 5

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

Я рассмотрел атрибут Explicit , который имеет преимущество в том, что его можно запускать без перекомпиляции, но он не принимает аргумент "причина", и в версии NUnit мы выполнить, тест не будет отображаться в выводе как невыполненный.

Answer 6

# 5 на Джоэле «12 шагов к лучшему коду» исправляет ошибки перед тем, как написать новый код:

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

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

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

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

Но если вы действительно хотите игнорировать провальные тесты, используйте атрибут [Ignore] или его эквивалент в любой используемой вами тестовой среде. В HTML-выводе MbUnit игнорируемые тесты отображаются желтым цветом по сравнению с красным, если тесты не пройдены. Это позволяет легко заметить недавно провалившийся тест, но вы не потеряете след из известных провальных тестов.

Answer 7

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

ТОДО - это хорошо. Используй их. Активно управляйте ими, фактически регулярно откладывая их в очередь.