If you are developing with a virtual machine or container, any modules installed by PIP will either be installed globally or potentially in a virtualenv location outside of the project root. Therefore you will need to tell PyCharm that the imported modules you’re using are located remotely, not locally.

First you will need to go into Preferences/Settings and to the Project specific settings, then into the Interpreter section.

You will then be able to add a Remote Interpreter, which will be the credentials required to log into your VM or container via SSH by PyCharm.

If you are using Vagrant then the location of the SSH key that can be used to login to the VM can be found by using the vagrant ssh-config command, which will output something like this.

If PostgreSQL is set to only listen and allow connections from localhost (127.0.0.1) then you can change the configuration to allow other or all IP addresses to connect.

First we will need to make sure PostgreSQL is listening for connections outside of local networking in the main configuration, which should be located somewhere such as /etc/postgresql/9.x/main/postgresql.conf (where 9.x is whichever version you have installed) so just uncomment the listen addresses line

Assuming you have a Vagrantfile setup to forward port 8080 and/or 8443 to the default http and https ports on the web server running in the VagrantVirtual Machine guest, you can forward these ports to the normally reserved ports on your Mac OS X host

If you prefer to use a client for MySQL such as Workbench, you can connect to the MySQL service in your Vagrant Virtual Machine by using SSH tunnelling. Run “vagrant ssh-config” to get the information you need to configure your client correctly.

You should see 2 keys listed under IdentityFile, use the path of the first one (not the insecure one) as the location for your SSH Key File in a new Standard TCP/IP over SSH connection in Workbench or an equivalent client. The SSH connection will be over whichever port Vagrant is forwarding (usually 2222, see the Port from the ssh-config output) with the user “vagrant” and the MySQL connection details will be whatever credentials are allowed to connect from within the VM.

However if you do not have easy access to the filesystem where Behat is being run, such as your Continuous Integration server (especially container-based solutions like Travis where it will get destroyed after each build) then it may be handy to upload it to somewhere and output the URL in your build logs. This is a quick solution for uploading to Imgur.

Please note this is a quick and dirty example, as it should ideally use Guzzle to talk to the Imgur API and use external configuration, but since people may want to use different image hosting services or methods I left it fairly basic for now.

If you are using Behat with Selenium server and running locally, if is firing up real browser instances via web driver then it is easy to see what may be going wrong. However if you are using a headless browser such as PhantomJS this makes it impossible, unless you take screenshots when an error has occured (a failed step in your scenario)

If you have an application that you are trying to test locally (such as on a Vagrant VM) or on a development server that has a self-signed certificate, Behat will probably complain of an SSL certificate problem because of an invalid certificate chain (GuzzleHttp\Exception\RequestException)

This is because Guzzle (the http client used by Goutte, the default Mink driver) believes the connection to be insecure, which technically it is, but for testing purposes we can ignore this.

If your application (or stack) is configured for https only at all times this means you can’t switch to http to test, since that would be testing configuration that is not representative of your live environment. To circumvent this you can disable SSL verification for cURL in Guzzle.

If you are making Ajax or API calls from a Javascript library (such as via jQuery or Angular) then it will encode the URI initially, then the web server (such as Apache) will 301 or 302 redirect to the new URI and the Javascript library will encode them again, resulting in double-encoded characters.

If you have redirect rules such as http to https or trailing slash to non-trailing slash then you will need to update the URIs you are making requests to in the Javascript calls.

Haven’t confirmed if Nginx or other web servers are affected by this yet