Я изучаю методы и стратегии для масштабирования растущего числа интеграционных тестов на нашем текущем продукте, чтобы они могли (по-человечески) оставаться частью нашей разработки и процесса КИ.
При более чем 200 интеграционных тестах мы уже достигли отметки в 1 час, чтобы завершить полный тестовый запуск (на настольном компьютере разработчика), и это отрицательно сказывается на способности разработчика допустить запуск всего пакета как части рутинных push-процессов. Что влияет на мотивацию, чтобы быть дисциплинированным о создании их хорошо. Мы тестируем интеграцию только ключевых сценариев спереди назад, и мы используем среду, которая отражает производство, которая создается с нуля каждый тестовый прогон.
Из-за времени, которое требуется для запуска, это создает ужасный цикл обратной связи, и многие потраченные впустую циклы ожидают на машинах завершения тестовых прогонов, независимо от того, насколько сфокусированы тестовые прогоны. Не говоря уже о более дорогих негативных последствиях для потока и прогресса, здравомыслия и устойчивости.
Мы ожидаем, что тестирование интеграции будет в 10 раз больше, прежде чем этот продукт начнет тормозить (на самом деле, не знаю, но пока мы даже не начинаем с точки зрения возможностей). Мы должны, конечно, ожидать, что пройдем несколько сотен или несколько тысяч интеграционных тестов, я считаю, в какой-то момент.
Чтобы было ясно, попытаться не допустить, чтобы это стало обсуждением модульного тестирования или интеграционного тестирования (которое никогда не должно продаваться). Мы проводим как модульное тестирование с TDD, так и интеграционное тестирование в этом продукте. Фактически, мы проводим интеграционное тестирование на различных уровнях архитектуры сервисов, которые у нас есть, где это имеет смысл для нас, так как нам необходимо проверить, где мы вносим серьезные изменения при изменении шаблонов в нашей архитектуре на другие области система.
Немного о нашем техническом стеке. В настоящее время мы проводим тестирование в среде эмуляции (с интенсивным использованием процессора и памяти), чтобы выполнить наши тесты от начала до конца. Он состоит из веб-сервисов Azure REST, входящих в бэкэнд noSql (ATS). Мы моделируем нашу производственную среду, запустив эмулятор рабочего стола Azure + IISExpress. Мы ограничены одним эмулятором и одним локальным внутренним хранилищем для каждой машины разработчика.
У нас также есть облачный CI, который выполняет тот же тест в той же эмулируемой среде, а тесты в два раза дольше (2 часа +) в облаке с нашим текущим поставщиком CI. Мы достигли пределов SLA провайдеров облачных CI с точки зрения производительности оборудования и превысили их допуск во время выполнения теста. Чтобы быть справедливым для них, их характеристики не плохие, но, очевидно, вдвое хуже, чем настольный компьютер.
Мы используем стратегию тестирования - перестройку нашего хранилища данных для каждой логической группы тестов и предварительную загрузку тестовых данных. Несмотря на всестороннюю гарантию целостности данных, это добавляет 5-15% влияния на каждый тест. Поэтому мы думаем, что оптимизировать эту стратегию тестирования на данном этапе разработки продукта мало что можно.
Суть в том, что, хотя мы можем оптимизировать пропускную способность каждого теста (даже если на 30% -50% каждый), мы все же не будем эффективно масштабировать в ближайшем будущем с несколькими сотнями тестов. Сейчас, даже если час все еще превышает человеческий уровень, нам нужно на порядок улучшить процесс в целом, чтобы сделать его устойчивым.
Итак, я исследую, какие методы и стратегии мы можем использовать, чтобы значительно сократить время тестирования.
- Написание меньшего количества тестов не вариант. Давайте не будем спорить, что в этой теме.
- Использование более быстрого оборудования, безусловно, вариант, хотя и очень дорогой.
- Параллельное выполнение групп тестов / сценариев на отдельном оборудовании также определенно является предпочтительным вариантом.
- Создание группы тестов на основе разрабатываемых функций и сценариев является правдоподобным, но в конечном итоге не является надежным для доказательства полного охвата или уверенности в том, что изменения не повлияют на систему.
- Технически возможен запуск в облачной промежуточной среде вместо запуска в эмуляторе рабочего стола, хотя мы начинаем добавлять время развертывания к тестовым прогонам (~ 20 минут каждый в начале тестового прогона для развертывания материала).
- Разделение компонентов системы на независимые логические составляющие в некоторой степени правдоподобно, но мы ожидаем, что пробег будет ограниченным, поскольку ожидается, что взаимодействия между компонентами со временем возрастут. (то есть изменение может повлиять на других неожиданным образом - как это часто случается, когда система развивается постепенно)
Я хотел посмотреть, какие стратегии (и инструменты) другие используют в этом пространстве.
(Я должен верить, что другие могут видеть такие трудности, используя определенные наборы технологий.))
[Обновление: 16.12.2016: В итоге мы инвестировали больше средств в параллельное тестирование CI для обсуждения результатов: http://www.mindkin.co.nz/blog/2015/12/16/16-jobs]