Удалить или прокомментировать нерабочие тесты JUnit?

Если вы используете Junit 4 вы можете аннотировать эти тесты с помощью аннотации @Ignore .

Если вы используете JUnit 3, вы можете просто переименовать тесты, чтобы они не начинались с test .

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

Если они компилируются, но терпят неудачу: оставьте их. Это даст вам хорошую историю улучшений тестирования с течением времени при использовании CI. Если тесты не компилируются, а ломают сборку, закомментируйте их и просите разработчиков исправить.

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

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

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

Система CI, которая постоянно горит красным, бесполезна. Основное преимущество - поддерживать планку качества, а это становится намного труднее, если нет перехода, чтобы отметить падение качества.

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

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

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

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

Затем, чтобы предотвратить подобную ситуацию в будущем, установите плагин, аналогичный Hudson Game Plugin . Люди получают баллы во время непрерывной интеграции, например

• -10 нарушить сборку <- хуже
• -1 нарушить тест
• +1 исправить тест
• и т.д.

Действительно классный инструмент для создания чувства ответственности за модульные тесты в команде.

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

Если это не сработает, удалите их (у вас ведь есть контроль версий, верно?) и закройте тикет с комментарием типа "удалены неудачные тесты junit, которые, очевидно, не будут исправлены" или что-то более вежливое.

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