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

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

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

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

403 голоса | спросил MattDavey 20 Jpm1000000pmFri, 20 Jan 2012 15:11:10 +040012 2012, 15:11:10

12 ответов


402

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

Проверьте неудачный тест, но аннотируйте его с помощью @Ignore("fails because of Bug #1234").

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

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

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

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

ответил sleske 20 Jpm1000000pmFri, 20 Jan 2012 15:24:27 +040012 2012, 15:24:27
104
  

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

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

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

ответил Arseni Mourzenko 20 Jpm1000000pmFri, 20 Jan 2012 15:19:22 +040012 2012, 15:19:22
54

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

ответил AProgrammer 20 Jpm1000000pmFri, 20 Jan 2012 15:47:39 +040012 2012, 15:47:39
23

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

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

ответил Ben Voigt 20 Jpm1000000pmFri, 20 Jan 2012 19:29:43 +040012 2012, 19:29:43
16

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

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

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

  

Каковы тесты, которые нужно выполнить?

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

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

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

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

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

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

ответил David 20 Jpm1000000pmFri, 20 Jan 2012 21:49:33 +040012 2012, 21:49:33
13

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

ответил Yamikuronue 20 Jpm1000000pmFri, 20 Jan 2012 20:25:43 +040012 2012, 20:25:43
7

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

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

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

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

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

ответил Qwerky 25 Jpm1000000pmWed, 25 Jan 2012 21:13:01 +040012 2012, 21:13:01
5

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

ответил prusswan 21 Jam1000000amSat, 21 Jan 2012 09:02:19 +040012 2012, 09:02:19
5

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

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

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

ответил Keith Brings 20 Jpm1000000pmFri, 20 Jan 2012 23:20:48 +040012 2012, 23:20:48
5

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

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

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

ответил Wilka 25 Jpm1000000pmWed, 25 Jan 2012 17:34:47 +040012 2012, 17:34:47
4

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

ответил Ola Eldøy 23 Jpm1000000pmMon, 23 Jan 2012 12:59:33 +040012 2012, 12:59:33
3

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

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

ответил markijbema 23 Jam1000000amMon, 23 Jan 2012 11:06:21 +040012 2012, 11:06:21

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132