Installing ChromeDriver on VM

[justinlevi]

Following these instructions I was able to get Selenium & the Chrome Driver to work with my Behat Tests on the VM

sudo apt-get install libxss1 libappindicator1 libindicator7
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

sudo dpkg -i google-chrome*.deb
sudo apt-get install -f
sudo apt-get install xvfb
sudo apt-get install unzip

wget -N http://chromedriver.storage.googleapis.com/2.20/chromedriver_linux64.zip
unzip chromedriver_linux64.zip
chmod +x chromedriver

sudo mv -f chromedriver /usr/local/share/chromedriver
sudo ln -s /usr/local/share/chromedriver /usr/local/bin/chromedriver
sudo ln -s /usr/local/share/chromedriver /usr/bin/chromedriver
sudo apt-get install python-pip

source: http://christopher.su/2015/selenium-chromedriver-ubuntu/

I'm wondering if it would be helpful to turn this into an ansible recipe? I found this url but this is a bit over my head..

http://coryklein.com/ansible/2015/10/09/using-ansible-to-install-google-chrome.html

May try to figure this out but thought I'd ask first to see if anyone thinks this is a really bad idea for some reason. I tried installing the firefox browser too but was getting weird selenium errors when trying to run my behat tests.

Here's my behat.yml file for reference:

default:
  formatters:
    pretty: true
    progress: true
  gherkin:
    filters:
      tags: "~@skip"
  suites:
    default:
      contexts:
        - behatch:browser
        - behatch:debug
        - behatch:system
        - behatch:json
        - behatch:table
        - behatch:rest
        - behatch:xml
        - FeatureContext
        - Drupal\DrupalExtension\Context\DrupalContext
        - Drupal\DrupalExtension\Context\MinkContext
        - Drupal\DrupalExtension\Context\MessageContext
        - Drupal\DrupalExtension\Context\DrushContext
  extensions:
    Sanpi\Behatch\Extension: ~
    Behat\MinkExtension:
      base_url: http://ss.vm
      browser_name: 'chrome'
      goutte: ~
      selenium2:
        wd_host: "http://127.0.0.1:4444/wd/hub"
    Drupal\DrupalExtension:
      blackbox: ~
      api_driver: 'drupal'
      drush:
        alias: '@ss.vm'
      drupal:
        drupal_root: '/var/www/ss/docroot'
      selectors:
        message_selector: '.messages'
        error_message_selector: '.messages.messages-error'
        success_message_selector: '.messages.messages-status'

Here's the Behatch feature > Scenario I was testing from within PHPStorm

Feature: Homepage
  In order to make sure the homepage isn't jacked
  As a anonymous website user
  I need to see a few key things

  # Requires chrome driver installed based on these instructions
  # http://christopher.su/2015/selenium-chromedriver-ubuntu/
  # included in post-install.sh now though
  @javascript
  Scenario: Behatch Browser Test
    Given I am on the homepage
    When I hover "#block-bartik-branding"
    Then I should see the text "Home"

And here's the working output

ssh://vagrant@192.168.88.88:22/usr/bin/php /home/vagrant/.phpstorm_helpers/behat.php --format PhpStormBehatFormatter --config /var/www/ss/btests/behat.yml /var/www/ss/btests/features/Homepage/Homepage.feature:30
Testing started at 3:27 PM ...

1 scenario (1 passed)
3 steps (3 passed)
0m5.30s (29.47Mb)

Process finished with exit code 0

[oxyc]

@thom8 mentioned forking arknolls role https://github.com/beetboxvm/ansible-role-selenium. Not sure what the plans for either is but that's probably where this would make a nice addition.

[thom8]

@oxyc happy to accept PR's on this fork but the long term plan will be to split out the browser install functionality into a seperate role(s) to give more flexibility and better test coverage.

[kevinquillen]

It is actually easier IMO to run with SeleniumHQs Docker project instead of inject it all into DrupalVM.

https://github.com/SeleniumHQ/docker-selenium

It comes with Chrome and a VNC client and works well. Out of the box, DrupalVM works well for headless Selenium tests under Firefox. You can specify the Selenium server at the docker IP, and it will work.

I really should write up and post my blog post about how I went about getting it all to work.

FYI be aware that Behat releases are coming out and newer Mink 3.x releases are removing the OOTB step definitions. I am not sure what the impact would be on DrupalExtension yet.

I would actually recommend complimenting DrupalVM with the Selenium Docker, instead of try to match feature parity. It adds a lot more time to install a VM when you need Java and all the dependencies for it - whereas with the Docker stuff it is a lot faster and isolated into its own VM.

[justinlevi]

@kevinquillen 👍 Thanks for the awesome note. I'll definitely give the docker project a try.

A blog post on all this stuff would be fantastic at some point. I've been thinking about doing a writeup as well.

[geerlingguy]

@kevinquillen / @justinlevi / anyone else - I, too, would love for someone to do a good writeup/blog post on the topic. We could add a link to the post in the documentation and that way people could choose what kind of Selenium setup they want. For some, the built-in solution will do everything they need. Others with more needs would definitely want to build a more custom environment.

[justinlevi]

@kevinquillen So I was able to get the standalone-chrome.2.52.0 up and running on Docker. It may be a little faster for me but hard to say. My first time working with Docker so pretty excited to finally dive in!

I'm a bit conflicted by this approach though. The setup was easy enough once you understand the basics around the docker container etc. The issue I have is that it moves away from the single contained Drupal development environment that you could potentially achieve by getting everything setup and working on the VM. It also adds one more layer to the technology stack which gets me nervous.

I realize this is a highly subjective topic and I love learning different approaches to this stuff. The team I'm working with is really after a couple of core things:

1. A easy to setup development environment that mirrors test, staging, and production as closely as possible.
2. A way to implement BDD without having to worry too much about setup and configuration.

For me, I really don't care how long it takes for the VM to install as I'm rarely doing that once I get things configured and working. I would rather have an "easy button" where I know everything is setup and running to work in my drupal sites and write and run tests in the fastest way possible.

My biggest issue right now that I'm trying to figure out now is that working on a windows host, running a single javascript scenario is taking up to 13seconds. Most of the time is spent ssh'ing into the VM. This seems waaaaaay to long to me and I'm not really sure how to speed things up.

[thom8]

I'm also keen to test this out but my concern would be more in relation to provisioning time.
Would this increase the size of a preprovisioned base box?

We use a feature branch model so each branch is developed in isolation on top of "current production" including update hooks for any changes to the database, so the feature is easily testable and deployable.

Due to this, each feature needs to be built from a fresh version of prod, and so switching branches requires rebuilding to mitigate any conflicts. Our CI platform works the same way by checking out a branch and running db updates it can replicate the deployed state of any feature branch.

This has proven very useful as we can create a release at any time and only include branches that have:

• Proper test coverage
• Passing tests
• Approval from test team
• Approval from product manager

We have looked into other options rather than rebuilding each time but this has actually been useful as it's effectively testing the deployment to prod each time you checkout the branch which often picks up issues when a feature skips a release, as it will need rebasing to the new "current production".

Any major works are done on a project branch and project feature branches are based on this but the same principles apply.

[geerlingguy]

Let's merge this discussion into #421