Удалить или закомментировать неработающие тесты JUnit?

Question

В настоящее время я создаю скрипт сборки CI для унаследованного приложения. Доступны отдельные тесты JUnit, и я буду интегрировать выполнение всех тестов JUnit в сборку CI. Тем не менее, мне интересно, что делать со 100-ю сбоями, с которыми я сталкиваюсь в необслуживаемых тестах JUnit. Должен ли я:

1) Прокомментируйте их, поскольку они, кажется, имеют разумную, если не поддерживается, бизнес-логику в них в надежде, что кто-то в конечном итоге раскомментирует их и исправит их

2) Удалите их, так как маловероятно, что кто-то их исправит, а закомментированный код будет только игнорироваться или загромождать вечно

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

Answer 1

Неудачные тесты JUnit показывают, что либо

1. Тестируемый исходный код был обработан без поддержки тестов. В этом случае вариант 3 определенно стоит рассмотреть, или
2. У вас подлинный сбой.

В любом случае вам нужно исправить / просмотреть тесты / источник. Поскольку ваша работа состоит в том, чтобы создавать систему CI, а не фиксировать тесты, на вашем месте я бы оставил бомбу замедленного действия в тестах. Вы можете очень увлекаться аннотированными методами с JUnit 4 (что-то вроде @IgnoreUntil(date="2010/09/16")) и пользовательским бегуном, или вы можете просто добавить оператор if в первую строку каждого теста:

  if (isBeforeTimeBomb()) {
    return;
  }

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

Answer 2

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

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

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

Answer 3

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

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

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

• -10 сломать сборку <- хуже </li>
• -1 прервать тест
• + 1 исправить тест
• и т.д.

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

Answer 4

• Закомментируйте их, чтобы они могли быть исправлены позже.
• Создание отчетов о покрытии тестов (например, Cobertura ). Методы, которые должны были быть охвачены закомментированными вами тестами, будут указаны как не охваченные тестами.

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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