Question - see the @javascript in a broweser

[iefrati]

I use the @javascript on some of my behat testing, either to see what is going on in the browser or for some debugging.

When running behat test with selenium in a drupal vm, I do not get the browser window. Do i need to configure something unique?

my behat.local.yml is:

default:
  extensions:
    Behat\MinkExtension:
      base_url: 'https://testing.test.me/'
      goutte:
        guzzle_parameters:
          verify: false
      show_cmd: open -a Safari %s
      browser_name: chrome #firefox  # Set to chrome if using the chromedriver
  suites:
    default:
      contexts:
        - FeatureContext:
            testing_hostname: 'testing.test.me'
            bootstrap_database_dump: 'init_testing.sql'
            codebase_root: '/var/www/test'
            setup_script_dir: 'var/www/test/bin'
            setup_script: 'devsite_vm_ido'
            dbusername: 'testing'
            dbpassword: 'testing'
            dbname: 'init_testing'

[geerlingguy]

@iefrati - If you're running those tests within Drupal VM, there's no real GUI to go along with Drupal VM, so all browser tests are run 'headless' within the VM.

There are ways to get screenshots of the headless browser, I think, but I haven't tried doing that for a very long time.

The alternative is to install Java and the other dependencies on your localhost, and run all the tests there (so it can use your own FireFox/Chrome/etc. browser), and just run the tests against the site built inside Drupal VM.

[iefrati]

@geerlingguy I tried to run it from outside the vm, but I am getting
╳ SQLSTATE[HY000] [2002] No such file or directory (PDOException)

because my @BeforeSuite has
$pdo = new PDO("mysql:host=localhost", $params['dbusername'], $params['dbpassword']);

replacing localhost with 127.0.0.1
results in the following error
╳ SQLSTATE[HY000] [1045] Access denied for user 'testing'@'localhost' (using password: YES) (PDOException)

which I am not sure why I am getting this since the user is testing, and I can access the db with it

[PieterDC]

Running the tests from your local (host) is an option as long as the test does not need direct access to the database, unless we could proxy those requests to the VM. But then still, that part of the development environment is not portable while that's the exact reason why we're playing with Vagrant, to create a portable development environment.

In our case the test code bootstraps Drupal to be able to do some stuff we don't have to cover with the Selenium tests. Similar to what @iefrati does with his @BeforeSuite piece. And also similar to the Drupal API Driver from Drupal Extension http://behat-drupal-extension.readthedocs.io/en/3.1/drupalapi.html

The Drupal API Driver is the fastest and the most powerful of the three drivers. Its biggest limitation is that the tests must run on the same server as the Drupal site.

Adding v.gui = true

  # VirtualBox.
  config.vm.provider :virtualbox do |v|
    v.gui = true

spins up a VirtualBox window but doesn't magically (install and) launch a GUI.

Using vagrant_box: boxcutter/ubuntu1604-desktop in config.yml instead of a non-desktop box obviously does launch a GUI. But then still this role ansible-role-selenium uses the browser(s) headless (with xvfb).

I'm looking at https://github.com/Anomen/vagrant-selenium for some inspiration. I want to do minimal changes to just make it work.

[geerlingguy]

Note also—you can capture screenshots on failed tests (or really any time you need) using something along the lines of: acquia/blt#1152 (comment)

[PieterDC]

With all your respect, capturing screenshots on failed tests feels like debugging Drupal code with https://www.drupal.org/project/devel It is crazy helpful, like you say in acquia/blt#1152 (comment).

But being able to interact with a browser while the test is running is like step-debugging Drupal code. It's more efficient.

Meanwhile, we managed to get a visible browser while running tests with Selenium, see https://github.com/Kanooh/drupal-vm/tree/paddle-selenium-support
We didn't manage to contribute it back to Drupal VM yet, but feel free to improve upon our work.