Как сохранить устойчивость багажника при длительных испытаниях?

9

У нас есть три набора тестовых наборов:

  • "Небольшой" номер люкс, на запуск которого уходит всего пара часов
  • «Средний» номер, который занимает несколько часов, обычно запускается каждую ночь (ночью)
  • «Большой» набор, который занимает неделю + для запуска

У нас также есть несколько более коротких тестовых наборов, но я не буду на них останавливаться.

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

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

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

И имеет ли значение, если это централизованная система контроля версий, такая как SVN, или распределенная, как git?

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

дуб
источник
6
Я понятия не имею, над каким программным обеспечением вы работаете, но небольшой набор тестов, который занимает несколько часов, - это какой-то WTF. Если бы они работали быстрее, это было бы проще, нет способа упростить ваши тесты?
Бенджамин Банье
2
что такого "чрезвычайно раздражающего" в том, что ствол нестабилен? Не знаю, знаете ли вы, но одна из самых популярных стратегий ветвления даже называется нестабильным стволом
комнат
1
Есть много способов оптимизировать набор тестов (как и для любого другого программного обеспечения). Я понятия не имею, почему у вас так много времени, но вы можете, например, повторно использовать некоторые тестовые среды или просто использовать лучшие алгоритмы / структуры данных во время работы (профилирование помогает). Возможно также, что никто не нашел время для идентификации репрезентативных выборок, и вы просто проверяете каждый возможный ввод / вывод по некоторой ссылке. Возможно, ваша система сборки позволяет вам кодировать зависимости тестового кода, чтобы вам не нужно было запускать полный набор. И я знаю, что это был не твой вопрос, поэтому я сделал это комментарием, а не ответом.
Бенджамин Банье
1
... хм, ваш лучший вариант, вероятно, улучшит тестирование и ведение журнала приложений, чтобы легче было найти причину сбоя. Таким образом, нужно было бы найти и устранить причину сбоя, а не тратить усилия на «детективные расследования», чтобы выяснить, кто, когда и почему изменил конкретную строку кода ...
Гнат
1
@honk Некоторые тесты занимают много времени. Я работаю в компании, которая производит оборудование для сбора данных, и наш «частичный» тестовый прогон занимает около часа. Тесты должны делать различные типы измерений, и это просто требует времени.
Velociraptors

Ответы:

1

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

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

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

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

Карл Билефельдт
источник
1
-1 Работа с ветками - жизнеспособный вариант, но рекомендация без предложения проверить может принести больше вреда, чем пользы. Только тестирование может показать, выполнимо ли это для конкретного проекта или нет. Например, в проекте, который я делал около 2 лет назад, такое тестирование показало, что работа с ветвями требовала в ~ 7 раз больше усилий по сравнению с нестабильным стволом
комнат
Спасибо, Карл! Хотя это не то, что я надеялся выучить, это очень практичный подход, который может помочь мне решить проблему под рукой. И я согласен с тем, что работа в течение нескольких дней за транком редко вызывает проблемы интеграции.
Дуб
12

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

Самый выгодный способ решить эту проблему - начать разделять вашу кодовую базу и тесты на (независимые) подразделения.
Есть огромные преимущества для этого:

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

С другой стороны, управление вашей структурой VCS станет более сложным, но, по всей видимости, через целую неделю для вашего полного теста, вы можете взять на себя боль!

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

Йорис Тиммерманс
источник
1
Я никогда не говорил , что большое испытание атомное испытание, это тест люкс . Когда отдельный разработчик вносит изменения в элемент X, он запускает тесты, относящиеся к X - независимо от того, из какого набора тестов они созданы. Это в дополнение к еженедельному тесту, который проводится, чтобы убедиться, что изменение в одном месте не оказало неожиданного влияния на другое место. Но вы заметите, что, по крайней мере, такое разделение поможет ускорить тесты для конкретных модулей, сохранив при этом риск примерно на одном уровне.
Дуб
2
@ oak - Ну, в некотором смысле, пакет является атомарным, если запускать его все - это единственный способ убедиться, что код стабилен, но вы делаете хорошую мысль, поэтому я отредактировал свой ответ.
Йорис Тиммерманс
4
У нас есть огромные тестовые наборы для наших компиляторов, некоторые из которых занимают несколько дней, и я не думаю, что это необычно для программного обеспечения, такого сложного, как компилятор C ++. Дело не в том, что пакет определяет то, что следует считать «стабильным», а в том, что существуют миллионы различных примеров генерации кода, которые невозможно протестировать каждый день.
JesperE
1
@JesperE - это понятно, если огромный набор тестов не определяет «стабильный», а является гигантским тестом на здравомыслие. Я не ожидал бы, что полный набор (или даже средний набор) выйдет из строя очень часто.
Йорис Тиммерманс
1

Для SVN я не знаю о такой вещи, как «предварительная фиксация». Я думаю, что это может привести к коммитам и откатам, когда тест не пройден. Как говорит Док-Браун, единственный способ - зафиксировать временную ветку и позже объединить ее с транком.

Использование распределенного типа git или mercurial, я думаю, было бы возможно. Использование «тестирующего» хранилища и «стабильного» хранилища. Вы нажимаете на тестового представителя, тестируете его ночью, и, если все работает нормально, вы переходите от теста к стабильному. В противном случае вы откатываете тестовую репутацию. Я немного не уверен, как будет выглядеть история версий, когда вы переходите от тестирования к стабильной версии, но я думаю, что при этом можно исключить испорченные откатанные вещи. Сначала немного экспериментов будет самым безопасным.

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

dagnelies
источник
1

ИМХО, это не имеет никакого отношения к VCS, который вы используете. Использование «тестируемой» ветви может быть решением, которое также может быть реализовано с помощью централизованных или распределенных VCS. Но, честно говоря, я думаю, что лучшая вещь в вашей ситуации - это попытка оптимизировать средний набор тестов (кажется, что он содержит самые важные тесты), чтобы он работал намного быстрее, и вы можете использовать его для pre-commit-to-trunk тесты, так же, как вы делаете это сейчас со своим "небольшим набором".

Док Браун
источник
Я в основном спрашиваю о методологии здесь - то есть, есть ли общий способ справиться с такой ситуацией. Предположим, по крайней мере, ради этого обсуждения, что тесты нельзя оптимизировать сверх того, что они уже есть.
Дуб
@ Ок: кто-то здесь (ты?) Проголосовал за мой ответ, но иногда вещи, которые ты не хочешь слышать, - это единственное, что поможет. Как вы видите в обсуждении ниже вашего вопроса, другие предложили то же самое, поэтому мое предложение не кажется таким уж плохим.
Док Браун
+1, это правильный ответ. Реальный вопрос ОП: «Помогите, я тону в дерьме, какую методологию я могу использовать, чтобы помочь себе?» и ответ таков: на самом деле методология - это не то, о чем вам следует беспокоиться.
MrFox
1

Неудачные средние тесты: правда ли, что в большинстве случаев одни и те же тесты не проходят?

Если есть сбой, всегда ли одни и те же связанные тесты, которые провалились?

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

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

k3b
источник
1

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

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

Вот что я предлагаю:

1) Сделайте тесты настолько атомарными, насколько это возможно, и максимизируйте повторное использование среды.

2) Получите тестовую ферму для их запуска. Если вместо 8 больших модулей у вас получится 50, вы можете раскрутить кучу спотовых экземпляров Amazon EC2 и запустить весь комплект параллельно. Я уверен, что это будет стоить денег, но сэкономит огромное количество времени на разработку.

MrFox
источник
0

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

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

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

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

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

Майкл Слэйд
источник