Должен ли я регистрировать отказ?

Question

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

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

---

@Paul Tomblin,

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

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

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

Answer 1

Я бы сказал: «Ад, да!». Простым фактом является то, что он не работает? Да! Затем он должен быть зарегистрирован. Вы в значительной степени компрометируете свое тестирование, разрешив провалившийся тест.

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

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

Answer 2

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

Answer 3

Он должен оставаться отказом, если это не делая то, что ожидалось.

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

- Kevin Fairchild

Answer 4

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

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

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

Answer 5

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

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

Answer 6

Мы добавили функцию «отсрочки» в наши модульные тесты. Это позволило аннотировать тест с атрибутом, который в основном сказал «игнорировать неудачи за X недель с этой даты». Разработчики могли бы аннотировать тест, который, как они знали, не исправлялись какое-то время с этим, но в будущем ему не потребовалось какое-либо вмешательство в его повторное включение вручную, тест просто вернется в тестовый пакет в назначенное время.

Answer 7

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

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

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

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