Сломанные старые / устаревшие юнит-тесты

Я работаю в большой компании и отвечаю за большое Java-приложение с тысячами тестов Junit. С тех пор, как я перешел на эту роль, было 200-300 сломанных тестов (вероятно, сломанных в течение многих лет). Тесты старые и хрупкие, и они представляют собой кучу спагетти-зависимостей, которые обычно заканчиваются живыми данными песочницы.

Моя цель - 100% пройти тесты, чтобы мы могли сломать сборку при сбоях модульных тестов, но я не смогу это сделать, пока не решу проблемы с тестами. У меня очень маленький бюджет, потому что бюджет на техническое обслуживание в основном предназначен для поддержки, но моя команда выявила и исправила тесты с минимальными результатами (в основном проблемы с конфигурацией / локальными ресурсами), и мы сократили до 30-40 действительно уродливых тестов.

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

Я думаю, что мы должны задокументировать статусы неработающих тестов с помощью всего, что мы знаем, а затем либо полностью удалить, либо проигнорировать неработающие тесты, и ввести элемент с ошибкой / работой с более низким приоритетом, чтобы исследовать и исправить их. Затем мы достигнем 100% и начнем извлекать реальную выгоду из других тестов, и если у нас будет непредвиденный случай обслуживания / рефакторинга, мы сможем снова их забрать.

Какой будет лучший подход?

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

То, что я бы сделал, это сначала отключил тесты, которые терпят неудачу и всегда терпят неудачу.

Сделайте так, чтобы тест не удался.

В ходе расследования вы можете спросить людей, которые были в вашей компании дольше, о них может быть много племенного знания о них, которое вы можете задокументировать / зафиксировать. Может быть из ваших журналов VCS. «О, этот тест всегда терпел неудачу, так как мы обновились до X», или другая информация может быть полезна.

После того, как вы узнаете, что за тестируемая функциональность была, вы можете определить:

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

А затем составьте список приоритетов.

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

Я бы сделал следующее:

1. Попытайтесь точно определить, что проваливаются тесты, которые проваливаются.

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

3. Исправьте все, что не так с вашим рабочим кодом, теперь, когда у вас есть хорошие тесты.

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

200-300 сломанных тестов (вероятно, сломанных на годы).

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

Моя цель - 100% пройти тесты, чтобы мы могли сломать сборку при сбоях модульных тестов, но я не смогу это сделать, пока не решу проблемы с тестами.

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

Я думаю, что мы должны задокументировать статусы неработающих тестов с помощью всего, что мы знаем, а затем либо полностью удалить, либо проигнорировать неработающие тесты, и ввести элемент с ошибкой / работой с более низким приоритетом, чтобы исследовать и исправить их. Затем мы достигнем 100% и начнем извлекать реальную выгоду из других тестов, и если у нас будет непредвиденный случай обслуживания / рефакторинга, мы сможем снова их забрать.

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

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

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

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

В каком-то смысле вам повезло. Лучше иметь тесты, которые не проходят и не должны (они дают вам предупреждение, по крайней мере, что-то не так), чем тесты, которые проходят и не должны (которые дают вам ложное чувство безопасности).
Конечно, если у вас есть первое, вполне вероятно, что у вас также есть второе (так что тесты, которые проходят, но должны провалиться).

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

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

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

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

Что касается знания племен, то если люди со знанием племен все еще рядом, они уже должны были исправить провальные испытания. Если нет, то опять же, это не приоритет.

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

Создавайте новые релевантные тесты и продолжайте писать отличный код.