Я столкнулся и сумел решить эту проблему.
Ключевой проблемой является тот факт, что версия ChromeWebdriver (2.29) была либо несовместима с версией Google Chrome (59.0), либо имела ошибку в отношении настройки файлов cookie (в Changelog упоминается некоторая работа с куки-файлами).
Рабочее сочетание для меня в настоящее время - ChromeDriver 2.30 + Google Chrome 59.0 - проверьте эти версии.
Другая вещь, которую я должен был изменить, - обработчик сеанса, чтобы использовать правильные сеансы вместо mocksess (ионов). В app/config/config_test.yml
Я изменить раздел framework
>session
так:
framework:
test: ~
session:
handler_id: session.handler.native_file
save_path: '/tmp/php-sessions'
И еще одна вещь, чтобы проверить, есть ли сеансы создаются/чтения/записи без каких-либо проблем разрешения. Я столкнулся с проблемой в какой-то момент, когда я работал с пользователем vagrant
, поэтому он создал файл сеанса с этим пользователем как владельцем, но когда он перешел через Selenium/Chrome обратно на веб-сервер, он попытался получить к нему доступ с помощью пользователя www-data
и не удалось из-за ограничений разрешений. В качестве обходного пути теперь я работаю под пользователем www-data
: sudo -E -u www-data bin/behat ...
. Аналогичные проблемы могут возникнуть и для кэшей.
Кажется, что для Бродячих каталогов специально Sylius силы кэша/журнала, которые будут помещены в /dev/shm/sylius
, что в случае совместной директории (между хозяином и гостем) является повышение производительности, но и предполагает строгие проверки разрешений (см https://github.com/Sylius/Sylius/blob/79a5285/src/Sylius/Bundle/CoreBundle/Application/Kernel.php#L162-L164)
Вы используете метод open() внутри неудачного шага? Кажется, он проверяет, находится ли он на определенной странице по URL-адресу, но находит другую страницу. – lauda
Я столкнулся с той же проблемой. Я не понимал, что это никак не связано с бродячей ВМ (но да, моя проблема тоже в VM). Вам удавалось решить эту проблему? Если да, ответите ли вы, пожалуйста? – mkilmanas