Zack Tollman

Unit Test Hack Day Prep

On Saturday, April 27th, PDXWP is hosting a hack day focusing on unit testing. Max Cutler, who has contributed significantly to WordPress core unit tests, will be teaching the group about unit testing.

WordPress core unit tests are written using PHPUnit. While PHPUnit is not the only unit testing framework for PHP, it is what WordPress has adopted and therefore, our hack day will focus on PHPUnit.

One of the most frustrating aspects of PHPUnit is getting it set up in the first place. Ideally, we will spend our time on Saturday learning to write unit tests, discussing how to improve unit tests, and getting our projects to pass the tests. Hopefully, we will not spend our time trying to get PHPUnit configured.

To this end, I have stood on the giant shoulders of Jeremy Felt and 10up by adding PHPUnit and the WordPress core unit tests to their outstanding Varying Vagrant Vagrants (VVV) vagrant setup. Instead of painstakingly writing a tutorial on how to install PHPUnit on OS X, Linux and Windows (and then trying to work around difficulties with MAMP, WAMP, XAMPP, etc.), this vagrant setup will build a virtual environment for you to work with locally during the dev day.

Getting Setup

  1. Install Virtual Box .
  2. Install Vagrant.
  3. Add “192.168.50.4 local.wordpress.dev local.wordpress-trunk.dev” to your hosts file.
  4. Determine where you want to store your vagrant files. I store mine in “~/Vagrant” on OS X.
  5. Clone VVV to your hard drive with, “git clone git@github.com:10up/varying-vagrant-vagrants.git”.
  6. Move to the cloned directory (e.g., “cd varying-vagrant-vagrants”).
  7. Run “vagrant up”.

You will now see a lot of output from your terminal. The base box will be downloaded, the server will be created, and the provisioning script will be executed, which installs a LEMP stack with a WordPress installation and the core unit tests. This can take between 10-30 minutes and is highly dependent upon your download speed (read: don’t try this at Starbucks or on the hack day!).

To test if you have correctly setup the box, visit “http://local.wordpress-trunk.dev” in your browser. If everything installed properly, you should see an installation of WordPress with the Twenty Thirteen theme.

To learn more about this vagrant setup, you can read the box’s description read me.

Running Unit Tests

  1. In terminal, navigate to your clone of the VVV repo.
  2. Run “vagrant ssh”. You are now ssh-ed into the virtual machine.
  3. Run “cd /srv/www/wordpress-unit-tests”.
  4. Run “sudo phpunit”

You should now see a lot of output:

You are seeing the WordPress unit tests running! In order to not spoil the fun, I will let Max explain what is going on during our meetup!

Your Job

Your job is simple–get PHPUnit working before the hack day. We will all have a lot more fun if everyone is already setup in advance. We can then focus on writing tests instead of setup up the tool. If you have questions, please have at it below! We will be happy to help.

Posted in MeetingsTagged , , , , 32 Comments

32 thoughts on “Unit Test Hack Day Prep”

  1. hi zak,

    this will work on a laptop with a full OS on it, but what about those of us working on iOS/iPads and Android tablets? can’t make vagrant/virtual box work with those (yet), i could VNC back into my desktop at home, but that’d be reeeeeeeeeeeeeal slooooooooooow getting anything done. should those of us with mobile iOS/Android devices not attend, or will we be able to participate also? please advise.

    — faddah

    1. There is really no good way to do this on a tablet device. The only thing I could think of would be to get it set up on a remote server, then use an app on your tablet device to SSH into the server to write the code and run PHPUnit. Even without depending on Vagrant, there is not a good way to manage this with a tablet.

      I would recommend at least stopping in for the initial presentation. There is a lot to learn from that.

  2. Pingback: Unit Test Hack Day Prep | danielbachhuber

  5. Looks like it was 1.1.5 and 1.2.1. Vagrant didn’t clean up an old version on upgrade. Cleaned-up manually, and unless I’m missing something VVV is still not working on Windows. Following up with Jeremy/10up directly (with real output from failure, go figure)

    1. Mike, have you heard from Jeremy on this issue yet? I too am running on Windows. The stable version of the site (local.wordpress.dev) runs fine, but when I try to access the trunk version (local.wordpress-trunk.dev) I get a 403 “Access Forbidden” page. I SSHed into the VM and did a ‘chown -R www-data:www-data www’ to make sure all the files and folders were under correct ownership, but that didn’t help. I did not some error message on the initial ‘vagrant up’ but I neglected to record them. I may do a ‘vagrant destroy’ and then do ‘vagrant up’ again just to see what that error message was. If I recall correctly it had something to do with downloading the trunk version.

      1. I haven’t tried with the latest versions yet, but last time I played with VVV I ran into a Windows-specific problem with svn. I ended up switching to the GitHub repo, which is just a mirror of the svn repo. I went into the provision.sh file and made two changes:

        comment out svn checkout and add

        git clone https://github.com/WordPress/WordPress.git /srv/www/wordpress-trunk

        comment out svn up and add

        git pull origin

      2. For everyone following … it’s worth noting that I have VVV working on Windows. It’s just a daily from somewhere between tag 0.4 and 0.5. I’m in the process of debugging 0.5 and the bleeding edge version now.

        —

        @Robert, I haven’t heard back yet. My problem & the failure point are reported on the VVV repo here, https://github.com/10up/varying-vagrant-vagrants/issues/56. Please take a look at it and add any details or your own failure messages if you can.

        @Corey, the command line SVN worked fine for me, but I’ve put svn on this machine’s Path. If you’re using a GUI SVN install on Windows that’s not always the case — which means we could be fighting a lot of machine-specific issues.

        The right fix for Windows might be to come up with a detailed set of Windows requirements for VVV (so far: svn in your path, Cygwin likely helps too, others?) and possibly a Windows batch or WSH script that triggers a Windows “Allow this…” prompt.

      3. @Corey – Do you have details on the SVN issue? SVN should live entirely inside the virtual machine during provisioning once installed via apt-get.

      4. @Jeremy it should, but there’s a problem when SVN is doing a checkout to a directory that is synced between the guest box and the host. It throws an error like this:

        Can’t move ‘.svn/tmp/entries’ to ‘.svn/entries’

        Haven’t pinned down the cause yet. I thought it might be Win7-specific, but Mike says he got it to work …

      6. As a workaround, are the WP unit tests available as a git repo anywhere? Switching to git for downloading/updating trunk is working for me.

    2. Sorry for the problems Windows users 😦 This was supposed to be the way to avoid these issues. I know a number of 10up folks are using this exact setup successfully. @jeremyfelt will have more information on that. This is why we are getting started early!

      1. It should be noted that Vagrant is a rapidly evolving piece of software. For the best experience, make sure you have Vagrant 1.2.1 and Virtualbox 4.2.12 installed. Follow Vagrant development at https://github.com/mitchellh/vagrant as new releases are pushed every week or two. I will often destroy all of my boxes with `vagrant destroy` whenever upgrading my versions of Vagrant and Virtualbox to try and avoid any confusion.

      2. Hey Zack, I think I figured it out. Hat tip to @teraphy for putting me on the right path. It turns out you can set core.autocrlf in three different git config files: global, system, and local.

        Vagrant’s provisioning script appears to have the issues I found when you run autocrlf-=warn (I think because vagrant hides any warnings or treats them as unexpected output).

        I added a .gitattributes to 10up’s repo in PR#57 that should force .sh files to be checked out with LF endings with newer (v1.8+ ?) git clients.

  6. @Corey I cannot reply above, but the WordPress unit tests are available here: https://github.com/kurtpayne/wordpress-unit-tests. The readme addresses the step you need to take to install them. I initially went this route; however, wp-cli does the extra step of writing the config file for you, which makes scripting this simpler.

    1. @Corey, are you running your shell as Windows Administrator? Not being able to move the SVN tmp folder seems like a permissions issue.

      2. @Mike, SVN checkout is working for you, yes? Are you on Win7 or Win8? Which distro of SVN are you using?

    2. @Zack, what is the name of the database, username, and password to put into wp-tests-config.php when manually installing the tests?

      1. This is from the provisioning script. It should more than likely be the same:

        –dbname=wordpress_unit_tests –dbuser=wp –dbpass=wp

      2. Thanks! That seems to have done the trick.

        There was an error message when I ran phpunit: ‘sh: 1: /usr/sbin/sendmail: not found’ which was repeated a total of 7 times. This same error message appeared in the log I kept of the initial ‘vagrant up’. Any idea what’s causing this?

      3. This likely has to do with sendmail not being setup in the Vagrant box. This is a minor issue for the hack day purposes. Unless you plan to work on issues that specifically involve sendmail during the hack day, this will not be important to fix. If you do want to working on such issues, I am sure @jeremyfelt would accept a PR for adding sendmail 😉

  9. I tried this and got this error: And now I have to leave to get there, so I guess I’ll be trying to sort this out while everyone hacks. If anyone has any insight, it’s much appreciated.

    Vagrantfile:6:in `’: undefined method `configure’ for Vagrant:Module (NoMethodError)

    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config/loader.rb:115:in `load’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config/loader.rb:115:in `block in procs_for_source’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config.rb:41:in `block in capture_configures’
    from :10:in `synchronize’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config.rb:36:in `capture_configures’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config/loader.rb:114:in `procs_for_source’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config/loader.rb:51:in `block in set’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config/loader.rb:45:in `each’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/config/loader.rb:45:in `set’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/environment.rb:377:in `block in load_config!’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/environment.rb:392:in `call’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/environment.rb:392:in `load_config!’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/lib/vagrant/environment.rb:327:in `load!’
    from /Applications/Vagrant/embedded/gems/gems/vagrant-1.0.6/bin/vagrant:40:in `’
    from /Applications/Vagrant/bin/../embedded/gems/bin/vagrant:23:in `load’
    from /Applications/Vagrant/bin/../embedded/gems/bin/vagrant:23:in `’

  10. Pingback: Unit Testing Hack Day Recap | Portland WordPress Meetup

Comments are closed.