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

410

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

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

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

MattDavey
источник
75
+1; очень провокационный вопрос. Я могу видеть обе стороны.
Карл Манастер
28
Вы используете термин «сборка», чтобы включить «тесты», что не является универсальным пониманием.
Джей Базузи
19
Если вы выполняете TDD, вы напишете провальный тест, затем исправите код и зарегистрируйтесь . Таким образом вы избежите сломанной сборки.
dietbuddha
7
По той же логике вы должны выключать живые экземпляры клиентов, пока не решите проблему. Нет, ты не должен нарушать сборку. Позвольте разработчику, работающему с ошибкой, добавить модульный тест, и код изменится вместе. Не нужно останавливать весь процесс.
Танос Папатанасиу

Ответы:

412

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

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

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

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

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

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

sleske
источник
150
+1 Я думаю, что вы попали в точку с «планированием исправления - это деловое решение» - как разработчик, я не могу судить, чтобы решить, не будет ли ошибка нарушена при сборке.
MattDavey
22
Я думаю, что это очень разумное решение. Особенно, если следующий парень, который проверяет какой-то незначительный код, внезапно получает уведомление «проваленный тест» и думает, что он что-то сделал.
Хольгер
14
«Для меня, как только ошибка помещена в базу данных ошибок, это больше не моя проблема» ... +1
Джейк Бергер
20
@anon За исключением Тойоты. Работник линии видит дефект, затем тянет за шнур, и весь завод останавливается, и управление переходит, и линия не перезапускается, пока проблема не будет устранена. Google Andon Cord. Это не новая концепция. смотрите: startuplessonslearned.com/2008/09/…
Кристофер Махан
4
@AndresJaanTack: Конечно, это будет зависеть от вашей методологии, но в целом я бы не согласился. По крайней мере, в бизнес-среде планирование работы - это бизнес-решение, которое включает исправление ошибок . Иногда новая функция (или выпуск на определенную дату) может быть более ценной, чем исправление (незначительной) ошибки - в этом случае исправление ошибки должно быть отложено. «Исправление ошибки сейчас» было бы неуместно в этой ситуации, потому что это задерживает более важную работу.
слеске
106

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

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

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

Арсений Мурзенко
источник
Я понимаю вашу точку зрения, и в целом я согласен - но в данном случае мы говорим о серьезной ошибке, которая
привела
3
Смотрите второй абзац моего ответа.
Арсений Мурзенко
8
Я понимаю, я думаю, что суть в вашем первом абзаце подытожена - не разработчик должен судить о серьезности ошибки или о том, является ли это пробкой, это решение для более широкого бизнеса.
MattDavey
4
Вопрос в том, что является приоритетом этой ошибки? Это может быть OMG FIX IT NOW, это может быть да, это раздражает, мы должны исправить это в какой-то момент, это может быть что-то посередине. Но не все ошибки будут встречаться в одном и том же месте в этом спектре.
Захари К
55

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

AProgrammer
источник
20
«Список неудачных тестов не заменяет систему отслеживания ошибок» +1, также очень хороший момент :)
MattDavey
1
Я бы посоветовал, чтобы регрессионные юнит-тесты вводились в базу кода как часть исправления, а не раньше.
yrk
6
@yarek: регрессионные тесты могут входить в кодовую базу в любое время, их просто нужно игнорировать, пока ошибка не будет исправлена. Я обычно разрабатываю их при диагностике проблемы, потому что тогда они могут использоваться как средство отладки.
Слёске
Это хороший пример того, почему «ломать сборку» становится токсичной частью рабочего места, где КИ превращается просто в «развитие, основанное на вине». Я сидел на многих собраниях, где PHB начинает жаловаться на "небрежность", как будто именно поэтому сборка сломалась. В такой среде вы вряд ли намеренно отметили бы что-то, что сломало сборку. В противном случае PHB расстроится. Сломай строй, надень конус позора. Что за дерьмовая практика.
Уоррен П
@WarrenP, иногда возникают другие проблемы, но давайте будем ясны, небрежность - первая причина, почему сборки ломаются. Если вы знаете, что что-то сломало сборку, зачем регистрироваться?
AProgrammer
23

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

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

Бен Фойгт
источник
12
Это не всегда правильно, часто команды рассматривают неудачный тест как неработающую сборку - фактически, большинство команд, которые я видел в последнее время, делают (это типичная гибкая практика). В большинстве гибких команд неудачный тест - это случай, когда вы останавливаете линию - вся команда атакует проблему и решает ее. Полагаю, я мог бы воспринимать ваш пост как означающий, что ответ должен основываться на вашей практике, и в этом случае он абсолютно точен.
Билл К
2
Я всегда считаю, что провальный тест означает, что сборка не удалась.
Джон Сондерс
@JohnSaunders: Но это не то, что это значит. Как я сказал в своем ответе, это означает, что «сборка имеет известные дефекты».
Бен Фойгт
1
@ сказал, что тестов не было? Где ты это взял? Я имею в виду, что мой первый шаг после обнаружения ошибки состоит не в том, чтобы помешать успешной сборке, а скорее в создании подробного отчета об ошибке. Когда ошибка устраняется, сначала должен пройти неудачный юнит-тест.
Джон Сондерс
1
У меня есть небольшая проблема с немедленным созданием провального теста. Я просто не хочу, чтобы он регистрировался в наборе тестов, которые будут выполняться при сборке. Я также хочу, чтобы разработчик, который исправляет ошибку, мог игнорировать этот тест. В большинстве мест, где я работал, люди, которые создают отчет об ошибках, не будут создавать модульные тесты.
Джон Сондерс
16

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

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

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

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

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

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

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

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

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

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

Дэвид
источник
1
Ваше утверждение неверно, модульные тесты не обязательно соответствуют непосредственно бизнес-требованиям, в то время как функциональные или сквозные тесты, вероятно, делают, но OP говорил о модульных тестах / TDD.
Джон Бьюкенен
@JohnBuchanan: Какие тесты предназначены для проверки, если нет, что программное обеспечение делает то, что должно делать? (То есть соответствует требованиям.) Как вы заявляете, существуют и другие формы тестов, кроме модульных. Но я не вижу значения в модульных тестах, которые не подтверждают, что это программное обеспечение отвечает потребностям бизнеса.
Дэвид
1
@JohnBuchanan - он не сказал, что «тесты являются отражением требований бизнеса», он сказал «ДОЛЖНО БЫТЬ». Что является правдой, но спорно. Вы правы, утверждая, что это не всегда так - некоторые люди пишут модульные тесты, которые не соответствуют бизнес-требованиям - хотя (на мой взгляд) они ошибаются в этом. Если вы хотите утверждать, что утверждение Дэвида неверно, вы можете сказать кое-что о том, почему вы так думаете.
Дауд ибн Карим
13

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

Yamikuronue
источник
4
Я думаю, что идея @ MattDavey превосходна, и я доказывал это в прошлом. Я всегда встречал каменную стену сопротивления - «ты никогда не должен ломать строй!». Идея, что сборка уже сломана в этой ситуации, кажется невозможной для понимания людьми. К сожалению, это просто еще один случай, когда хорошая идея (автоматическое тестирование и чистые сборки) превратилась в культовую культуру, приверженцы которой знают правило, но не причину.
Том Андерсон
3
Одна идея, с которой я пришел, заключается в том, что команде QA (если она достаточно техническая, чтобы писать тесты) должно быть разрешено писать тесты на ошибки для проверки и проверять их. Зацикленность разработчиков на зеленой полосе приведет к абсолютно расставление приоритетов по исправлению ошибок над добавлением функций, что является правильным способом разработки.
Том Андерсон
Но это не должны быть модульные тесты, которые будут выполняться во время сборки. Если ваша среда содержит систему управления тестированием для QA (например, Microsoft Test Manager), то, безусловно, необходимо добавить один или несколько тестовых примеров и связать их с ошибкой, но это не помешает успешной сборке - это будет просто тест случай, который должен пройти до того, как ошибка будет считаться "Готово".
Джон Сондерс
7

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

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

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

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

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

Qwerky
источник
5

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

prusswan
источник
«если нет способа обозначить такие тесты, как ни красные, ни зеленые». Просто для справки: большинство платформ модульного тестирования различают красные, зеленые и игнорируемые тесты. По крайней мере, JUnit и TestNG делают (они сообщают "xx test, x fail, x игнорируется").
слеске
@Sleske, что было бы идеально, я просто хочу быть уверен, что игнорирование сбоев автоматически не приводит к успеху
prusswan
Разве там нет ЖЕЛТЫХ строений? (Красный / Зеленый / Желтый) в Гудзоне / Дженкинсе, Круиз-контроле и всех других важных вещах?
Уоррен П
@Warren P это работает, когда люди игнорируют тесты правильно, но некоторые игнорируют тесты, делая их зелеными
prusswan
5

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

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

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

Кит Брингс
источник
5

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

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

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

Wilka
источник
1
Ваше тестовое программное обеспечение должно сообщать вам, когда что-то недавно сломалось, по сравнению с тестом, который не прошел раньше.
Бен Фойгт
4

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

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

markijbema
источник
4

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

Ола Элдой
источник