Вопрос

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

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


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

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

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

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

Это было полезно?

Решение

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

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

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

Другие советы

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

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

Это должно оставаться неудачей, если оно делает не то, что ожидалось.

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top