When I started PHP development, it was with WAMP Sever installed locally. This gave me local installations of Apache, MySQL, and PHP that let me run WordPress while still offline. It was great.
Well, actually it sucked, but I was new enough to the game I didn't know any better.
My first attempt was actually to install all three applications locally on Windows manually. I was able to get MySQL and PHP running, but Apache gave me headaches. I was working between a laptop and a desktop at the time, so I installed everything on the desktop and just accessed them over the local network.
This worked, but it wasn't very portable. For the life of me, though, I couldn't get the software to run on my laptop ... so i switched instead to WAMP.
The only issue I had (at first) with WAMP was that it interfered with Skype (both would attempt to bind to port 80, so I'd have to start WAMP first otherwise they'd collide). Then I needed to upgrade PHP because WordPress bumped their requirement to 5.2.
Three days of frustration later, I dropped WAMP for XAMPP. It did pretty much the same thing, but had a smaller footprint, was easier to install, and had a nifty toolbar option that allowed me to start/stop the entire suite of apps at a moments' notice.
Unfortunately, XAMPP still sucked.
Fast forward a few years and I was given the opportunity to help build VVV with a smart team of developers both within and nearby to 10up. VVV uses virtual machines to entirely sandbox a local development environment - PHP, Apache, Nginx, whatever are all installed on the virtual machine and not your local environment.
When I got a Mac, I started with VVV. The only tools I have installed locally are Node (for project management), PHP (for Composer at the command line), and Composer (for project management).
When I got a new PC, I started again with VVV (albeit this time on top of Hyper-V instead of VirtualBox).
The improvement in my workflow has been enormous! Well, except for needing to boot the virtual server to do just about everything.
Unit Testing
Except for unit testing projects built with WP_Mock.
I'm a huge proponent of decoupling development projects as much as possible, which is why I'm also a huge opponent of direct SQL queries within WordPress. The direct database calls mean that, to test WordPress core programatically, you must have a database configured and available - otherwise function calls will fail fatally.
This is why the WordPress Unit Test Framework requires you set up a local database against which to run your tests. I hate that.
Next week I'll be giving two separate talks about unit testing at php[world] in Washington, DC. One of my talks will cover the benefits of the WP Test Framework, but the gem of each is the WP_Mock tool I've developed with John Bloch of 10up and the dev team at TechCrunch.
This tool allows me to mock WordPress' core API when I'm testing my theme and plugin code. That means I don't even need WordPress installed in order to test my code. Nor do I need a local database.
Just my code itself, and PHP (so I can install Composer and manage the project's dependencies).
Want to see such a system in action?
- Clone my HTTP utility project to your machine
- Navigate into the project directory from the command line
- Run [cci]composer install[/cci] to pull down project dependencies
- Now run [cci]vendor\bin\paratest[/cci] to run the test suite[ref]Unfortunately, this command requires a *NIX style command line. Windows users will still have to run this from within a VM or some sort of Bash-style command environment.[/ref]
You've now cloned a project, used PHP/Composer to pull down its dependencies (including WP_Mock, PHPUnit, and Paratest), then used PHP/Paratest/PHPUnit to run a test suite with 100% coverage. On a WordPress project. Without installing WordPress, a web server, a database, or anything else you'd normally have to install.
You've tested code locally, and kept your environment clean at the same time.
When I started writing code for WordPress, I thought something like this would be impossible. Look how far we've come ...