01.08.2023 10:00
Ale2Da 0 210 Источник

Много тестов - это хорошо, особенно если они еще и по делу.

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

Вдохновившись описанными получаемыми результатами:

, пробуем использовать ferrum вместо "медленных" selenium-webdrivers.

Чтобы получить относительно сопоставимые результаты, сделаем отдельный MR и сравним, что получится ДО и ПОСЛЕ.

Количество и качество тестов - одинаковое в данном случае.

Настройки

Как и описано, например вот здесь - Proper browser testing in Ruby on Rails (evil martians), настройки не представляют большой сложности.

Gemfile
...
+  gem 'cuprite'
-  gem 'webdrivers'
...

Конфигурация драйвера

Capybara.server = :puma, { Silent: true }
Capybara.register_driver :cuprite do |app|
  # FIXME: Two different keys for headless mode exist - one for Capybara (Cuprit) and one for Chromium - headless mode
  # [Chrome's headless mode](https://developer.chrome.com/articles/new-headless/#new-headless-in-selenium-webdriver)
  # It's impossible to set two keys with the same values - does not work

  if ENV['HEADLESS'].in?(%w[n 0 no false])
    browser_options = { 'no-sandbox': nil }
    headless = false
  else
    browser_options = { 'no-sandbox': nil, headless: 'new' }
    headless = 'new'
  end
  options = {
    browser_options:,
    window_size: [1600, 1200],
    inspector: true,
    headless:
    # js_errors: true
    # slowmo: 2,
    # process_timeout: 15
  }

  Capybara::Cuprite::Driver.new(app, options)
end

Capybara.save_path = DownloadHelpers::DOWNLOAD_PATH || './tmp/capybara'
# disable CSS transition and jQuery animation
Capybara.disable_animation = true
# Usually, especially when using Selenium, developers tend to increase the max wait time.
# With Cuprite, there is no need for that.
# We use a Capybara default value here explicitly.
# Capybara.default_max_wait_time = 2

# Normalize whitespaces when using `has_text?` and similar matchers,
# i.e., ignore newlines, trailing spaces, etc.
# That makes tests less dependent on slightly UI changes.
Capybara.default_normalize_ws = true

Capybara.javascript_driver = :cuprite

Запуск. Ошибки

Как и описано в упомянутых источниках и в ссылках внизу, часть тестов завершилась с ошибками. Примерное количество - 15-20% от общего числа.

Ошибки поделились на несколько категорий.

Самая распространенная

  • перестают работать одни из самых используемых методов - click_link (и его разновидности, например find('#id_blabla').click).

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

Это "что-то еще" оказалось используемыми css наподобие ::before, используемыми bootstrap и bulma для, например, смены background строки таблицы при наведении.

Везде, где применяются еще какие то дополнительные анимационные css, метод click_link не будет работать.

Пользуясь подсказкой ferrum (или cuprite), меняем click на trigger('click'), игнорируя предупреждение о том, что возможно нажимаем не совсем в той области, где планировали.

Обнаруживается вторая ошибка - метод trigger('click') на "нормальных" без css линках не работает.

Делаем два разных шага в cucumber для устранения данных ошибок, разбираемся, где линки с css, а где нет - и в результате большая часть (примерно 95%) тестов начинает работать с новым драйвером.

Ошибка два

Часть тестов, использующих прямой вызов JS для того, чтобы установить или получить значение из применяемых компонент, не работает.

Устанавливаемые значения - все срабатывает, а вот возвращается всегда nil.

В описании Ferrum JavaScript находим, что для выполнения JS и выполнения с возвратом значения используются разные методы (evaluate/execute).

Возможно при реализации Cuprite этот нюанс не был учтен, меняем метод там, где необходимы значения и тесты начинают работать.

Ошибка три

Вызвана тем, что headless и headful режим работает различно. Проявляется это просто - в режиме headful тест выполняется, в режиме headless - падает с ошибкой, связанной с тем, что не отрабатывает стандартная функция onchange: 'this.form.submit()'.

Руководствуясь документом от Google Chrome’s Headless mode меняем headless mode на новую.

Здесь возникает еще один не очень понятный момент, связанный с тем, что mode определяется в ДВУХ местах. В настройках параметров драйвера и в настройках параметров браузера драйвера. В итоге пока оставляем так, как приведено выше в конфигурации.

И после этого все тесты начинают работать.

Результаты

Это не benchmark, это просто вывод времени выполнения каждого теста для одной и той же группы тестов, на одной и той же локальной машине.

Исходные данные:

Количественные показатели тестов

  • Cucumber 70 scenarios (550 steps)

  • RSpec 346 examples

Характеристики компьютера

  • Linux version 5.15.0-76-generic (buildd@lcy02-amd64-028)

  • Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz

  • 16373244 K total memory

Измерения скорости выполнения тестов

Измерения проводились исключительно с целью примерного сравнения без применения каких либо специализированных инструментов.

Для "усреднения" использовалась command-line benchmarking tool

cuprite

  • RSpec
    (Migrate_to_ferrum) hyperfine --runs 5 'bundle exec rspec'
    Benchmark 1: bundle exec rspec
    Time (mean ± σ): 127.121 s ± 0.743 s [User: 90.705 s, System: 11.023 s]
    Range (min … max): 126.002 s … 127.780 s 5 runs

  • Cucumber
    (Migrate_to_ferrum) hyperfine --runs 5 'bundle exec cucumber'
    Benchmark 1: bundle exec cucumber
    Time (mean ± σ): 165.294 s ± 1.112 s [User: 112.951 s, System: 20.299 s]
    Range (min … max): 164.166 s … 166.902 s 5 runs

selenium-webdrivers

  • Rspec
    (master) hyperfine --runs 5 'bundle exec rspec'
    Benchmark 1: bundle exec rspec
    Time (mean ± σ): 121.184 s ± 0.684 s [User: 83.846 s, System: 8.371 s]
    Range (min … max): 120.355 s … 122.083 s 5 runs

  • Cucumber
    (master) hyperfine --runs 5 'bundle exec cucumber'
    Benchmark 1: bundle exec cucumber
    Time (mean ± σ): 156.351 s ± 0.834 s [User: 103.068 s, System: 22.487 s]
    Range (min … max): 155.059 s … 157.337 s 5 runs

Сравнительная таблица:

Driver

RSpec

Cucumber

Selenium

120.355 s … 122.083 s

155.059 s … 157.337 s

Cuprite

126.002 s … 127.780 s

164.166 s … 166.902 s

Легенда:

  • Selenium - тесты с использованием драйвера selenium-webdrivers и Chrome

  • Cuprite - тесты с использованием драйвера cuprite и Chrome

Результаты, мягко говоря, неожиданные.

Близкие результаты Rspec определяются тем, что шагов с capybara там немного.

А вот для cucumber - половина шагов использует capybara.

Еще немного о странностях

Дальнейшее изучение проблемы с быстродействием драйвера ferrum привело к совершенно неожиданным результатам.

Одни и те же тесты в одном и том же окружении при смене версии браузера ведут себя совершенно по разному.

Для примера:

Версия браузера 108.0.5359.98 (Официальная сборка), (64 бит) - у коллеги на машине, linux

  • Падает один тест, который до этого не падал. Ошибка связана с тем, что не работает функция onclick. Возможно в этой версии браузера headless еще "старой" конструкции.

Версия 114.0.5735.198

  • все тесты выполняются без ошибок.

Google Chrome 115.0.5790.102 - последняя на текущий момент.

  • начали падать ДВА теста. Стабильно. На разных (двух) машинах, с MacOS и Linux. При этом попытка "разобраться", в чем там дело, завершилась несколько неудачно. Эти же тесты, но запущенные по ОДНОМУ - не падают вообще.

Предварительные выводы

Плюсы:

  • Возможность использования дополнительных инструментов для позиционирования, заполнения, анализа страницы

  • Отладка - возможность debug с текущей страницей - это просто замечательно. Подробности см. (https://github.com/rubycdp/cuprite#debugging)

  • Большое кол-во дополнительных полезных функций, как то ожидание ответа по AJAX, поиск по css и т.д. Справедливо будет отметить, что все эти "дополнительные" методы относятся к драйверу ferrum, а не к cuprite. Примерно так же можно использовать аналогичные методы selenuim, так что этот плюс можно считать весьма условным.

Минусы:

  • Поведение с разными версиями браузера ???

  • Быстродействие ???

Пока полученные результаты не позволяют сделать вывод о целесообразности замены selenium-webdrivers на ferrum.

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

Возможно проблема в том, что именно тестируется с помощью capybara.

Используемые нами тесты - это стандартные интеграционные тесты и не включают тестирование интерфейса как такового.

Активно используется поиск и заполнение полей, чек-боксов, выбор из списков, управление JS компонентами типа редактор tinyMCE и т.д.

Все тестируемые компоненты форм требуют авторизации, здесь используется стандартный helper от devise и в случае selenium-webdrivers, и в случае ferrum.

Вполне возможно, что быстродействие можно будет увеличить за счет использования предоставляемого механизма управления сессиями и отказа от использования sign-in.

Но это уже несколько иная ситуация, тем более, что при наличии различных ролей проблема не будет решена.

А проводить тестирование под условным "суперпользователем" как то не очень логично, особенно, если тестируются ограничения этого доступа.

Полученные результаты не позволяют сделать вывод о целесообразности замены используемого драйвера selenium-webdrivers на ferrum по состоянию разработки на текущий момент.

  • ferrum (0.13)

  • cuprite (0.14.3)

  • Rails 7.0.6

Используемые источники

Комментарии (0)