Как избежать сбоя отложенных запросов после отката базы данных в интеграционных тестах? - PullRequest
0 голосов
/ 24 апреля 2019

У нас возникла периодическая проблема, и я хотел бы посмотреть, есть ли здесь кто-то, кто понимает, как мы можем ее решить.Мы проводим интеграционные тесты с использованием безголового драйвера Minitest + Capybara и Chrome.

Эта проблема возникает, когда тест завершен и база данных получает ROLLBACK'd.Все еще могут быть некоторые незавершенные запросы, работающие в фоновом режиме, и могут возникать сбои (например, RecordNotFound), если они пытаются получить доступ к информации базы данных.

Такая проблема чаще всего возникает из-за запросов AJAX и длядля этого мы уже используем помощник wait_for_ajax (который мы разработали сами), чтобы дождаться, пока Браузер закончит с его запросами.

Неразрешенная проблема возникает с <img> тегами HTML, потому чтобраузер все еще может пытаться загрузить изображения асинхронно, даже если тесты завершены.

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

test 'image popup should contain some class' do
  upload_some_images # Uploads images
  visit '/list_of_images' # Some page with list of images, you can click on the image and it opens it in a popup

  find('.image-popup-open-button').click # Open image in a popup window
  assert_selector '.some-class-must-be-present'
end

Этопростой тест, но в нашем случае он всегда вылетает с ошибкой ActiveRecord::RecordNotFound blob id=xxx.

  • При открытии всплывающего окна в DOM добавляется <img src='/files/123' />.Затем браузер запрашивает это и перенаправляется на URL-адрес представления ActiveRecord.
  • Интеграционный тест довольно прост и проверяет, присутствует ли какой-либо класс, затем тест завершается и база данных ROLLBACK'd.
  • Запрос на /files/123 все еще выполняется, который затем пытается загрузить BLOB-объект (запись в базе данных), который больше не существует, что приводит к неожиданному сбою теста.

Кто-нибудь когда-либобыла такая проблема, если да, то как вам удалось ее избежать?

Мы используем Ruby 2.5.0, Rails 5.2.2, Capybara 3.0.3

Спасибо

Ответы [ 2 ]

1 голос
/ 24 апреля 2019

Предполагая, что Capybara управляет запуском тестируемого приложения, Capybara.reset_sessions! будет ожидать завершения всех открытых запросов. Это должно произойти до отката БД. При использовании системных тестов Rails это будет обрабатываться в блоке teardown, если вы вызываете super из любых блоков teardown, которые вы определили. Если вы не используете системные тесты и просто основываете свои тесты на IntegerationTests, вам нужно определить teardown блок, который вызывает Capybara.reset_sessions!, чтобы он дождался завершения всех запросов, прежде чем Rails откатит БД.

0 голосов
/ 24 апреля 2019

Оказалось, что мы реализовали Capybara следующим образом:

def after_teardown
  super
  Capybara.reset_sessions!
  Capybara.use_default_driver
end

, но Rails выполняет откат базы данных при вызове super after_teardown. Таким образом, база данных была откатана до того, как Capybara ожидает окончания сеанса.

Перемещение super после Capybara.reset_sessions! сделало свое дело (вместо этого имеет смысл поместить его внутрь def teardown, что, скорее всего, и будет сделано).

Спасибо @ThomasWalpole за то, что указал мне правильное направление.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...