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

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

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

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

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

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

  # Tests expected to fail go here
}

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

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

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

Пример: необходимо протестировать 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 отказавших". Таким образом оставляя программиста, чтобы решить ту проблему (сначала) и не обработать 3.2.3. и 3.2.4. потому что это не удалось бы.

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

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

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

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

TODO's хорош. Используйте их. Активно управление их путем фактического помещения их в отставание регулярно.

5. На "12 Шагах Joel к Лучшему Коду" исправляет ошибки перед написанием нового кода:

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

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

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

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

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