Intro

Wiring up Laravel, Laradock [Laravel+Docker] and PHPStorm to play nice together complete with remote xdebug’ing as icing on top! Although this guide is based on PHPStorm Windows,
you should be able to adjust accordingly. This guide was written based on Docker for Windows Native.

Installation

This guide assumes the following:

you have already installed and are familiar with Laravel, Laradock and PHPStorm.

you have installed Laravel as a parent of laradock. This guide assumes /c/_dk/laravel.

hosts

Add laravel to your hosts file located on Windows 10 at C:\Windows\System32\drivers\etc\hosts. It should be set to the IP of your running container. Mine is: 10.0.75.2
On Windows you can find it by opening Windows Hyper-V Manager.

Firewall

Your PHPStorm will need to be able to receive a connection from PHP xdebug either your running workspace or php-fpm containers on port 9000. This means that your Windows Firewall should either enable connections from the Application PHPStorm OR the port.

It is important to note that if the Application PHPStorm is NOT enabled in the firewall, you will not be able to recreate a rule to override that.

Also be aware that if you are installing/upgrade different versions of PHPStorm, you MAY have orphaned references to PHPStorm in your Firewall! You may decide to remove orphaned references however in either case, make sure that they are set to receive public TCP traffic.

You will need to run chromedriver with headless and no-sandbox flag. In Laravel Dusk 2.x it is
already set headless so you just need to add no-sandbox flag. If you on previous version 1.x,
you will need to update your DustTestCase#driver as shown below.

Option 2: With Selenium

Intro

Setting up Laravel Dusk tests to run with Laradock appears be something that
eludes most Laradock users. This guide is designed to show you how to wire them
up to work together. This guide is written with macOS and Linux in mind. As such,
it’s only been tested on macOS. Feel free to create pull requests to update the guide
for Windows-specific instructions.

This guide assumes you know how to use a DNS forwarder such as dnsmasq or are comfortable
with editing the /etc/hosts file for one-off DNS changes.

DNS Setup

According to RFC-2606, only four TLDs are reserved for local testing1:

.test

.example

.invalid

.localhost

A common TLD used for local development is .dev, but newer versions of Google
Chrome (such as the one bundled with the Selenium Docker image), will fail to
resolve that DNS as there will appear to be a name collision.

The recommended extension is .test for your Laravel web apps because you’re
running tests. Using a DNS forwarder such as dnsmasq or by editing the /etc/hosts
file, configure the host to point to localhost.

For example, in your /etc/hosts file:

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
127.0.0.1 myapp.test

This will ensure that when navigating to myapp.test, it will route the
request to 127.0.0.1 which will be handled by Nginx in Laradock.

Docker Compose setup

In order to make the Selenium container talk to the Nginx container appropriately,
the docker-compose.yml needs to be edited to accommodate this. Make the following
changes:

...
selenium:
...
depends_on:
- nginx
links:
- nginx:<your_domain>

This allows network communication between the Nginx and Selenium containers
and it also ensures that when starting the Selenium container, the Nginx
container starts up first unless it’s already running. This allows
the Selenium container to make requests to the Nginx container, which is
necessary for running Dusk tests. These changes also link the nginx environment
variable to the domain you wired up in your hosts file.

Laravel Dusk Setup

In order to make Laravel Dusk make the proper request to the Selenium container,
you have to edit the DuskTestCase.php file that’s provided on the initial
installation of Laravel Dusk. The change you have to make deals with the URL the
Remote Web Driver attempts to use to set up the Selenium session.

One recommendation for this is to add a separate config option in your .env.dusk.local
so it’s still possible to run your Dusk tests locally should you want to.