Непрерывная интеграция и стратегия автоматизированного тестирования

Question

Я работаю в компании, которая использует непрерывную интеграцию (TeamCity).Каждый раз, когда кто-то делает проверку в программном обеспечении CI, запускает сборку и запускает весь модульный / автоматический тест.Проблема в том, что мы получили более 7000 модульных тестов + 756 автоматических тестов (использовались для тестирования JavaScript, поскольку мы получили очень сложную логику пользовательского интерфейса для выполнения расчетов и т. Д.).Как вы видите, каждый раз, когда кто-то делает проверку во всем процессе, требуется более 2 часов, чтобы пройти все этапы (build-unitest-автоматизированный тест), поэтому мне нужно подождать так много времени, прежде чем я смогу получить результат, чтобы понять,моя регистрация сломала возможно автоматизированный тест или юнит-тест.В худшем случае, когда несколько человек регистрируют что-то, так что TeamCity начинает ставить в очередь сборку, и прежде чем я смогу получить действительный результат (без даты), я могу подождать до половины дня!Какую стратегию мы должны принять, чтобы немного ускорить этот процесс?Рекомендуется ли запускать все автоматизированные тесты даже с небольшими изменениями?

Answer 1

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

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

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

Возможно, вы также захотите улучшить свою CI-машину, в зависимости от характера ваших вещей, если рабочий каталог для тестов находится в tmpfs (RAM-диске).

Answer 2

Я собираюсь поговорить теоретически, мне еще предстоит применить это на практике, но КИ ставит перед собой цель подготовиться к концу лета.

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

Тогда выхотел бы настроить эти стандартные проверочные модули, чтобы запустить кратковременный тест для базовой проверки решения.Затем для ночных сборок и для развертываний - единственный раз, когда вам НУЖНО запустить полный набор тестов для проверки регрессионных тестов.

---

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

Answer 3

Рассматривали ли вы использование предварительно протестированных коммитов? Если вы запускаете сборку с дистанционным запуском (без фиксации в VCS), вы можете быть уверены, что ничего не сломали в VCS (только потому, что вы еще не фиксировали). И вы можете продолжать работать без проблем. Если сборка прошла успешно, вы можете зафиксировать свое изменение (даже если вы сделали какие-то другие изменения в тех же файлах) - если вы фиксируете через плагин TeamCity, он будет фиксировать именно тот код, который вы отправили на сервер для тестирования.

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

Отказ от ответственности: я разработчик TeamCity.

Answer 4

Непрерывная интеграция лучше всего работает с распределенной системой управления версиями, такой как Git или Mercurial .

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

Как только функция завершена локально, ее можно зарегистрировать в центральном хранилище.Таким образом, CI-сервер выполняет все трудоемкие тесты только после добавления новых функций и / или исправлений.