Я почти уверен, что в момент выхода из ruby любые дескрипторы или указатели на что-то вроде объекта браузера станут недействительными. Поэтому повторное использование чего-либо в более позднем процессе ruby, вероятно, не очень хороший подход. Кроме того, я могу ошибаться в этом, но кажется, что веб-драйвер не очень хорош для подключения к запущенному процессу браузера. Так что для вашего подхода к работе на самом деле все это нужно было бы обернуть каким-нибудь мастер-процессом, который вызывал все тесты и т. Д. И, эй, подождите секунду, это начинает звучать как фреймворк, который вы, возможно, уже (или, возможно, должны быть ) используя в первую очередь.
Таким образом, лучшее решение, вероятно, состоит в том, чтобы взглянуть на любую среду, которую вы используете для запуска своих тестов, и исследовать любую возможность действий 'setup / teardown' (которые могут иметь разные имена), которые выполняются до и после каждого теста, группы тестов или все тесты. Идти по этому пути хорошо, так как большинство фреймворков разработано так, чтобы вы могли запускать любой отдельный тест или набор тестов, которые вы хотите. И если ваши тесты хорошо спроектированы, их можно запускать по отдельности, не ожидая, что система была оставлена в каком-то идеальном состоянии в результате предыдущего теста. Таким образом, эти виды действий по настройке / демонтажу также предназначены для такой работы.
В качестве примера, Cucumber имеет это на уровне функций, с идеей «фона», который в основном предназначен для просушки сценариев, определяя общие шаги, которые нужно выполнить перед каждым сценарием в файле объектов. (например, переход на ваш сайт и вход в него). Это может включать в себя вызов последовательности шагов, которые проверят, существует ли объект браузера, а если нет, то создайте его. Однако вам нужно будет добавить это в каждый файл функций, который начинает становиться довольно сухим.
К счастью, огурец также позволяет сделать это в одном месте с помощью Крюков . Вы можете определить хуки для запуска перед шагами, в случае определенных условий, «до» и «после» каждого сценария, а также код, который выполняется один раз перед любыми сценариями, и код, определенный для запуска «at_exit», где вы можете закрыть браузер после всех сценариев.
Если бы я использовал огурец, я бы взглянул на идею некоторого кода в env.rb, который будет запускаться в начале, чтобы создать браузер, дополненный кодом at_exit, чтобы закрыть браузер. Затем, возможно, также код в хуке before, который может проверить, что браузер все еще там, и воссоздать его при необходимости, и, возможно, выйти из системы в хуке after. Оставьте такие вещи, как вход в систему для отдельных сценариев или блок background, если все сценарии в функции входят в систему с одним и тем же пользователем.