Должен ли я продолжать регистрировать сбой?

Question

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

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

---

@ Пол Томблин,

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

Должен остаться сбой, если он не выполняет ожидаемого.

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

- Кевин Фэйрчайлд

Answer 6

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

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

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

Answer 7

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

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

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