Как вы справляетесь с неудачными юнит-тестами?

Question

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

В настоящее время у меня нет времени, чтобы исправить все тесты, но я верю, что имеет смысл запускать существующие тесты. Как лучше всего справиться с неудачными юнит-тестами?

Что я сейчас делаю, так это помечаю каждый проваленный тест как явный и оставляю комментарий TODO.

[Test, Explicit] //TODO: Rewrite this test because it fails

Есть ли лучший способ сделать это? Или я должен исправить все тесты, прежде чем включать их в тесты, выполняемые в СНГ?

Answer 1

Поскольку у вас запущена автоматическая сборка (с уведомлением об ошибке теста!), Похоже, что пришло время 5 дней в день (бесплатно от сообщества ubuntu):

В каждом методе тестирования, который не работает, вставьте следующее (псевдокод):

if  ( DateTime.now < new DateTime(2008, 12, 24, 11, 00, 00)) return;

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

Когда наступает рабочий день, вы исправляете или удаляете его.

Answer 2

Ну, в NUnit у вас есть возможность игнорировать тесты, используя атрибут ignore:

[Test, Ignore("Test needs rewrite")]

Лично я с такими тестами делаю две вещи:

• Удалите их, если я не понимаю тест, или если тест устарел / не соответствует текущим спецификациям
• Измените его на правильную спецификацию, если исправление тривиально

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

Нет смысла проводить тест, который в любом случае никто не понимает.

ОБНОВЛЕНИЕ : У Орена Эйни есть запись в блоге, в которой рассказывается о том, что я чувствую по поводу активации старых неудачных тестов:

Тесты сами по себе не имеют значения. Мой самый успешный проект не имел тестов

Цитировать:

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

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

Answer 3

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

• Добавить комментарий, объясняющий, почему тест не пройден. Если это происходит из-за ошибки в другом месте, полезно использовать идентификатор ошибки и т. Д. Убедитесь, что вы предоставили достаточно информации, чтобы вернуться к ней через год.
• Иметь какой-нибудь инструмент (возможно, очень простой - grep!), Генерирующий отчет еженедельно, чтобы вы не забыли о тесте.
• Если возможно, найдите способ автоматического запуска игнорируемых тестов периодически, просто чтобы проверить, не прошли ли они до сих пор. Тест, который не прошел и по волшебству начинает работать, может дать очень важную информацию (конечно, в сочетании с историей источника).

Answer 4

У меня нет времени на то, чтобы исправить все тесты

Я думаю, у тебя есть что-то отсталое ...

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

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

Серьезно, какой смысл иметь тесты, если ты не слушаешь то, что они тебе говорят? И зачем беспокоиться о непрерывной интеграции, если вы не можете доверять тому, что она делает?

Answer 5

Вы хорошо выполняете настройку сервера непрерывной интеграции, на котором выполняются все ваши тесты.

Но для чего нужны отключенные тесты? Они как закомментированный код. Мертвые тесты. Как Джон сказал: заставить их бежать или удалить их. Часто лучше писать новые, если они плохо написаны, как вы говорите.

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

Answer 6

Что бы вы сделали с другим кодом, который накопил технический долг?

Если вы выполняете TDD (сначала тестируйте), модульные тесты сделают для вас две вещи. Одним из них является помощь в проектировании ваших объектов с низким сцеплением и высокой когезией. Эти тесты больше не делают дерьмо для вас. Во-вторых, позволяет вам рефакторинг вашего кода без изменения поведения.

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

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

Если вы удалите тесты, вам нужно будет обработать код, который предположительно был охвачен тестами, как "Legacy" (Определение Feather).