Должен ли я намеренно прервать сборку при обнаружении ошибки в производстве?

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

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

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

Наша стратегия:

Проверьте в неуспешном тесте, но пометьте его @Ignore("fails because of Bug #1234").

Таким образом, тест проводится, но сборка не нарушается.

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

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

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

Почему вы хотите разрешить сборку с известными дефектами?

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

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

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

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

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

Я бы поспорил, что провальный тест должен быть добавлен, но не явно как «провальный тест».

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

Что вы должны спросить себя в этой ситуации,

Какие тесты предназначены для выполнения?

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

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

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

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

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

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

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

Написание теста, который вы знаете, потерпит неудачу, пока ошибка не будет исправлена ​​- это хорошая идея, это основа TDD.

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

Пример 1
Что делать, если ваше приложение отличается большим количеством компонентов? Что если над этими компонентами работают другие команды с собственным циклом выпуска? Tough! Они должны ждать вашего исправления ошибки!

Пример 2
Что делать, если первую ошибку трудно исправить, и вы нашли другую ошибку с более высоким приоритетом? Вы также нарушаете сборку для второй ошибки? Теперь вы не можете строить, пока оба не исправлены. Вы создали искусственную зависимость.

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

Это зависит от роли, которую должны играть тесты, и от того, как их результаты должны повлиять на принятую систему / процесс сборки. Мое понимание взлома сборки такое же, как у Бена, и в то же время мы не должны сознательно проверять код, который нарушает существующие тесты. Если эти тесты пришли «позже», было бы «нормально» игнорировать их, просто чтобы сделать их менее ненужными для других, но я считаю, что такая практика игнорирования неудачных тестов (так что они кажутся успешными) довольно тревожна (особенно для модульных тестов), если нет способа указать такие тесты, как ни красный, ни зеленый.

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

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

Кроме того, в зависимости от вашей политики выпуска, наличие недавно обновленных модульных тестов может помочь подтвердить, что разработчик действительно исправил проблему, а не просто изменил ее [(проблему или тесты?)], Хотя это зависит от того, закодировал ли он правильные требования в новых модульных тестах.

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

Вы не хотите помогать своей команде войти в это мышление.

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

Хотя я думаю, что вы должны каким-то образом «зарегистрировать» ошибку как тест, чтобы, когда вы исправляете ее, она больше не повторялась и каким-то образом расставляла приоритеты, я думаю, что лучше не нарушать сборку (/ тесты) , Причина в том, что последующие коммиты, нарушающие сборку, будут скрыты за вашим неработающим тестом. Таким образом, проверяя неисправный тест на эту ошибку, вы требуете, чтобы вся команда отложила свою работу, чтобы исправить эту ошибку. Если этого не произойдет, вы можете нарушить коммиты, которые не прослеживаются как таковые.

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

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