I’m going to have a significantly longer post (or series of posts) that go more into detail about setting up WP-CLI, proper unit testing of WordPress plugins, and so on.
But for those who are already working on setting all of this up and are hitting a couple of problems with trying to set up a temporary database using some of the provided WP-CLI shell scripts, I wanted to share the solution that I used to resolve this.
MySQL Admin Can’t Connect To Localhost
The problem generally manifests like this:
You have a development environment setup on your local machine. It uses a different version of MySQL and MySQL Admin than what ships as the default binary on your machine.
When WP-CLI attempts to create the temporary database for the unit tests, you may get an error that MySQL Admin can’t connect to localhost.
Depending on the order in which you’ve installed the unit tests and configured your system, and depending on the set up of your path, then the way you need to address this problem will vary.
First, go ahead and end any processes that include MySQL. If you’re comfortable with using tools on the command line like
grep, then you can find the process IDs for MySQL and issue the
killall command to terminate the processes.
$ ps aux | grep "mysqld"
If that doesn’t work or that’s out of your wheelhouse, you can launch your process monitor. If you’re on OS X, that would be Activity Monitor, and you can search for “mysql.” You should see “mysqld” and you can terminate the process from the GUI.
After that, you can try running the WP-CLI command again. If that doesn’t work, then you may need to check to see if your path is executing the proper version of MySQL Admin.
You can do this by issuing the following command:
$ which mysqladmin
And the value that’s printed should point to the local of
mysqladmin on your system that corresponds to whatever you’re using in your development environment.
If not, then you have an environmental variable problem, and you’ll need to update your path. I wrote a post about Composer and WordPress recently, and the third point in the post will show you how to update your path.
Just change the values to that which corresponds to the location of MySQL and its associated tools on your system.
Finally, if you’re using a tool such as MAMP or another development environment, then you need to make sure that you give MySQL network access from your local machine.
After all is said and done, you’ll likely need to reload your
.bash_profile and/or restart all your services.
Once done, everything should work as expected and you should be able to execute the other scripts to spin up an environment for running your unit tests.