Должен ли я продолжать регистрировать сбой?
Я работаю над автоматизированным набором регрессионных тестов для приложения, которое я поддерживаю. При разработке автоматического регрессионного теста я столкнулся с некоторым поведением, которое почти наверняка является ошибкой. Итак, на данный момент я изменил автоматический регрессионный тест, чтобы не регистрировать сбой - он намеренно позволяет этому плохому поведению пройти, я имею в виду.
Итак, меня интересуют мнения других на этом сайте. Очевидно, я добавлю ошибку в наше отслеживание дефектов, чтобы убедиться, что это поведение исправлено. Но есть ли какие-либо веские причины (в любом случае) либо изменить регрессионный тест, чтобы постоянно указывать на неудачу, либо оставить регрессионный тест неработающим и не потерпеть неудачу, пока мы не сможем исправить дефектное поведение? Я думаю об этом как о 6 из полдюжины вопросов другого типа, но я спрашиваю здесь, потому что я думал, что другие могут увидеть это по-другому.
@ Пол Томблин,
Просто чтобы прояснить - я никогда не думал об удалении теста; Я просто подумывал об изменении условия прохождения / сбоя, чтобы сбой не появлялся у меня при каждом запуске теста.
Я немного обеспокоен повторяющимися сбоями по известным причинам, которые в конечном итоге рассматриваются как предупреждения в C++. Я знаю разработчиков, которые видят предупреждения в своем коде C++ и просто игнорируют их, потому что считают, что это просто бесполезный шум. Я боюсь, что оставление известной ошибки в наборе регрессий может привести к тому, что люди начнут игнорировать другие, возможно, более важные, ошибки.
Кстати, чтобы меня не поняли, я считаю, что предупреждения в C++ являются важным помощником в создании надежного кода, но, судя по другим разработчикам C++, с которыми я встречался, я думаю, что я в меньшинстве.
7 ответов
Я бы сказал "черт возьми, да!". Простой факт, это терпит неудачу? Да! Тогда это должно быть зарегистрировано. Вы в значительной степени компрометируете свое тестирование, позволяя пройти неудачному тесту.
Одна вещь, которая касалась бы меня лично, - то, что, если я сделал это, и пошел под шиной, тогда "заплатка" может не быть удалена, означая, что даже после "исправления" ошибка все еще может остаться.
Оставьте это, обновите заметки вашего проекта, возможно, даже уменьшите серьезность (если возможно), но, конечно, не нарушайте то, что проверяет на наличие сломанных вещей;)
Если вы перестанете его тестировать, как вы узнаете, когда он исправлен, и, что более важно, как вы узнаете, если он снова сломается? Я против сдачи теста, потому что вы, вероятно, забудете добавить его снова.
Мы добавили функцию "дремать" в наши юнит-тесты. Это позволило аннотировать тест с помощью атрибута, который в основном гласил: "игнорировать сбои в течение X недель с этой даты". Разработчики могут комментировать тест, который, как они знали, не будет исправлен какое-то время, но в будущем для его повторного включения не потребовалось никакого вмешательства, тест просто возвращался в набор тестов в назначенное время.
Это должно остаться неудачей, если он не делает то, что ожидалось.
В противном случае, это слишком легко игнорировать. Держите вещи простыми - это работает или нет. Неудача или успех:)
- Кевин Фэйрчайлд
Хотя я согласен с большей частью сказанного Полом, другая сторона аргумента заключается в том, что регрессионные тесты, строго говоря, должны проверять изменения в поведении программы, а не просто какую-либо старую ошибку. Они специально должны сообщить вам, когда вы сломали что-то, что раньше работало.
Я думаю, что это сводится к тому, какие другие виды тестов выполняются в этом приложении. Если у вас есть какая-то система модульного тестирования, возможно, это было бы более подходящим местом для этого теста, чем для регрессионного теста (по крайней мере, до тех пор, пока ошибка не будет исправлена). Однако, если регрессионные тесты являются вашими единственными тестами, я бы, вероятно, оставил тест на месте.
Хотя при наличии ошибок лучше всего не выполнять тесты, это часто нецелесообразный выбор. При первом добавлении теста в область особенно легко увязнуть в обнаруженных ошибках и, следовательно, не достичь основной цели. Кроме того, длительные испытания становятся настолько шумными, что их легче и легче игнорировать.
Написание неудачных тестов является частью исправления ошибок, и это действительно важно только тогда, когда исправление этих ошибок важно. Это должно определяться вашим текущим продуктом и приоритетами качества. Если вам случается производить тесты как побочный эффект каких-то других усилий, это хорошо, но нельзя позволять отвлекать вас от ваших реальных приоритетов.
Я бы рекомендовал делать любые обнаруженные ошибки, улучшая тестирование предупреждений и регистрируя ошибки против них. Это широкий подход, который поможет вам выполнить текущее задание, в то же время фактически используя то, что вы изучаете. Затем тесты можно легко превратить в настоящие сбои, когда ошибки планируется исправить.
В отличие от других респондентов, я думаю, что неудачи так же легко игнорировать, как и предупреждения, а стоимость обучения вашей команды игнорированию неудач слишком высока, чтобы это произошло. Если вы произведете неудачные тесты в рамках этих усилий, вы уничтожите утилиту вашего набора регрессионных тестов, когда задача улучшала ее.
Проведение теста проваливается. Существует различие между неработающим кодом и незавершенным кодом, и вопрос о том, следует ли немедленно обратиться к тесту, зависит от того, в каких обстоятельствах этот провальный тест подвергается.
Если он сломан, вы должны исправить это раньше, чем позже. Если он не закончен, разберитесь с ним, когда у вас будет время.
В любом случае, очевидно, что вы можете жить так, как будто он ведет себя плохо (на данный момент), поэтому до тех пор, пока проблема регистрируется, вы можете не допустить, чтобы она беспокоила вас, пока у вас не будет времени ее исправить.