Добавим в CI тесты производительности
⭐️ Запуск тестов на каждую сборку
Про такой опыт можно прочитать в книге Профессиональный бенчмарк, которую написал Андрей Акиньшин.
🔗 https://habr.com/ru/companies/piter/articles/598175/
В этом подходе речь идет о бенчмарках, не об e2e тестах. Бенчмарки быстрее и стабильнее e2e тестов, их можно запускать часто, на каждую сборку
Пример такого фреймворка для JVM - JMH
🔗 https://github.com/openjdk/jmh
Скорость выполнения тестов важна, и чем быстрее тем лучше. Чем меньше в тестах зависимостей, тем меньший объект тестируется, и тем быстрее получаются тесты
⭐️ Тесты на низкоуровневые события
Многие системы используют языки программирования, выполняемые в виртуальной машине, например, JVM. Где есть внутренний механизм записи событий, таких как аллокация нового участка памяти или отправка сетевого пакета или какие-то кастомные. Такой проект как
🔗 https://github.com/moditect/jfrunit
позволяет проверять что во время теста какие-то события были, также можно сделать проверки на количество событий. Например
assertThat(jfrEvents).
contains(JfrEventTypes.GARBAGE_COLLECTION);
Это позволяет сделать тесты не на время выполнения. Которое может значительно меняться от разных внешних параметров; и нужна статистическая база, чтобы отделить статистически значимые деградации производительности от мнимых - об этом частично книга Профессиональный бенчмарк. А на события. Тут нужно хорошо знать свое приложение, хорошо знать как оно работает внутри. И тогда можно сделать тест на то, что во время теста сборка мусора не была вызвана ни разу и что потоки не были в состоянии блокировки ни разу.
⭐️ Тесты на прикладные метрики
Иногда сложно сказать сколько низко уровневых событий сделает приложение. Для проекта jfrunit можно сделать привязку к кастомным JFR-событиям, как количество чтений какого-то объекта или количество транзакций. Но тогда эти JFR-события надо будет в коде задать.
⭐️ Тесты на количество SQL-запросов
А есть высокоуровневые метрики популярных фреймворков, которые с высокой вероятностью влияют на производительность. Например, есть ORM-фреймворки, которые генерируют SQL-запросы, и они могут сгенерировать N+1 запрос. Например, если есть объект "команда" а в ней есть список людей, то может получиться так, для для получения одной сущности "команда" будет 1 запрос на команду и еще N запросов для получения участников команды.
Тут могут помочь такие проекты как
🔗 https://github.com/quick-perf/quickperf
🔗 https://youtu.be/xxEr8K4hJYQ?si=u7z0rJzVWvTvy1Hs
где через аннотации подобные такой
@ExpectSelect(1)
можно задать ожидаемое количество SQL-запросов, что их тут будет 1, а не N+1.
⭐️ Умный выбор запускаемых тестов
Если добавить к процессу выбора тестов инструменты code-coverage, то можно автоматизировать запуск тестов только на измененные объекты. Тестов получится меньше, они выполнятся быстрее, чем полный набор тестов. А скорость выпуска сборки важна для более быстрых итераций
Пример такого решения от Gradle
🔗 https://docs.gradle.com/develocity/predictive-test-selection/
также есть решения на базе популярного инструмена JoCoCo
🔗 https://docs.gradle.org/current/userguide/jacoco_plugin.html
но два известных мне решения являются внутренеей разработкой, возможно и в моей компании есть такое решение в том числе и в вашей тоже
И есть варианты реализации, когда для тестов есть pipeline, есть автоматизация, но выполнение теста происходит реже, тогда тесты могут быть более длительными. И быть интеграционным тестами на базе таких инструментов как Apache JMeter, K6, Gatling и так далее
⭐️ Тесты до релиза
Также можно запускать тесты на не каждую сборку, а на каждый релиз, на каждый merge в главную ветку
⭐️ Тесты после релиза
Также можно запускать тесты не перед релизом, а после установки релиза на пред-продуктив. Запускать эти тесты на этом же окружении в ходе автоматических проверок после установки новой версии.
⭐️ Тесты по расписанию
Также можно не блокировать сборки, релизы и деплои, а запускать тесты по своему расписанию