Test-suite optimization

Author: beglov

case-study.md

@@ -0,0 +1,56 @@
+# Оптимизация времени выполнения тестов
+
+Для оптимизации был выбран рабочий проект.
+
+# Подготовка
+
+Первое что необходимо было сделать это замерить текущее время прогона всех тестов
+и настроить отправку этой метрики в `InfluxDB`.
+
+Изначальное время выполнения `1444` тестов оказалось почти `6` минут:
+
+```
+Finished in 5 minutes 54 seconds (files took 3.78 seconds to load)
+1444 examples, 0 failures
+```
+
+С отправкой метрик в `InfluxDB` возникли некоторые сложности.
+
+Вначале я хотел сделать отправку в cloud версию этой БД что бы не пришлось её разворачивать у себя,
+но по какой то причине данные туда не уходили, соединение с сервисом отваливалось по таймауту,
+так что пришлось отказаться от этой идеи.
+
+После чего я решил развернуть эту БД у себя локально с помощью `docker`-а. В процессе работы было выяснено
+что в `Chronograf`-е особой необходимости нет, т.к. контейнер с `InfluxDB` уже предоставляет неплохой
+интерфейс с возможностью отрисовки графиков и создания Dashboard-ов.
+
+Итоговый конфиг в докере для `InfluxDB` оказался таким:
+
+```yml
+services:
+  influxdb:
+    image: influxdb
+    ports:
+      - '8086:8086'
+    volumes:
+      - influxdb-storage:/var/lib/influxdb2
+
+volumes:
+  influxdb-storage:
+```
+
+В этой конфигурации данные успешно уходят в `InfluxDB`.
+
+# Оптимизация
+
+## parallel_tests
+
+После распараллеливания время прогона тестов упало с `360` до `150` секунд.
+
+### TODO
+
+Наибольшее время занимает прогон `feature` тестов, требующих браузера.
+В дальнейшем, по мере увеличения количества тестов,
+можно будет разделить запуск тестов на тесты требующие браузер (и долго выполняющиеся) и все остальные.
+И локально запускать только быстрые, не требующие браузера, тесты.
+Полный прогон в любом случае будет выполняться в CI.