Какова наилучшая практика для управления старым модульным тестом при отладке или добавлении новой функции?

Question

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

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

Или просто пропустить их? Спасибо.

Answer 1

Устаревшие юнит-тесты бесполезны. Если вы хотите, чтобы они были полезны, обновите их.

Answer 2

Если тест не пройден, есть три варианта:

1. Рабочий код не работает, и его необходимо исправить.
2. Тест не пройден (или не соответствует последним изменениям в рабочем коде), и тест необходимо исправить.
3. Поведение, указанное в тесте, больше не требуется, и тест можно удалить.

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

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

Answer 3

Конечно, вам нужно время, чтобы заставить их пройти. Зачем выбрасывать эту работу?

Вся идея TDD в том, чтобы все тесты проходили постоянно. С того момента, как вы начинаете говорить: «Эй, это нормально, что этот модульный тест не пройден», TDD бесполезен. Это требует некоторой дисциплины, да, но это того стоит.

Answer 4

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

Answer 5

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

Я бы обновил тесты.

Но сначала я бы выследил разработчика, который их сломал, и ... ну вот вам вдохновение .

Answer 6

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

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

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

Answer 7

Есть две возможные ситуации:

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