Про поиск гипотез

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

Интересно было понаблюдать, как более опытный разработчик строит гипотезы:

⚪️ сначала обсудили причины, по которым тесты не всегда стабильны (action-items пока не выделии, скорее для общего обзора проблемы)

⚪️ посмотрели на параметры параллельности (история изменений в гит - вывод: подобрано эмпирическим путем, какого-то особого смысла нет)

⚪️ скормили в ИИ-шку отчет об успешных тестах (всю папку отчетов, с их длительностью) и попросили нарисовать гистограмму (посмотрели общую картину, сколько тестов быстрых, сколько медленных)

⚪️ попросили ИИ-шку выгрузить список классов тестов и количество тестов в них, суммарное время выполнения по классам (если экспериментировать с цифрой параллельности, то примерно посчитать, как сильно можно распараллелить - так как тесты в одном классе скорее всего и будут выполняться на одной jvm)

⚪️ выбрали топ-10 по длительности и заигнорили эти тесты (для эксперимента)

⚪️ общая суммарная длительность тестов уменьшилась на пол часа (от трех часов исходно), но сама таска выполнялась все равно час (как и с полным набором тестов) - гипотеза "время тестов сократится" не сработала, значит, надо будет что-то другое придумывать.

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

Мне было интересно и полезно понаблюдать, как происходит анализ проблемы, какие гипотезы выдвигаются, какие схемы и диаграммы просить ИИ-шку нарисовать. Любопытно.