Run To The Future

This is probably obvious to most but I needed to do this to make PHP compile using mysql against the 64 bit header files:

./configure --with-libdir=lib64 --with-mysql

Not sure exactly what the problem is (sorry about that, could be related to mongo but I suspect not), but PHP 5.3.6 is breaking (many, but not all pages are "unavailable") our li3 application. PHP 5.3.5 works fine, as does PHP 5.3.7-dev.

This is really a note-to-self.

Sometimes when I run my unit tests in Lithium (li3) I get something like:

Exception thrown in lithium\data\Model::connection() on line 929:
The data connection `test` is not configured.

Which doesn't make any sense because our unit test classes inherit from our own Unit class, which determines which data connection to use, however in our Unit test class setUp method we have to tell every class we need to use to use the correct data connection. Also, we never use the data connection "test". (The "test" data connection is the one li3 chooses by default when tests are run, which is why we had to overwrite it in our Unit class.)

So why is this happening? Because a class that I'm using as part of the testing includes another class in itself, and so we also have to manually tell this file which data connection to use.

Probably a better way to do this :D

Lithium Acceptance Tests using Cucumber and Webrat

Introduction

Cucumber (aka. cuke) and webrat are ruby tools for behaviour driven development (BDD) and while they're mostly used on rails apps, they can be applied to PHP apps too. Our motivation for doing this comes from using a virtual machine (vm) for our (work) development. We're using lithium now for all new projects, and we want to do BDD and Test Driven Development (TDD) as well. TDD is fine – lithium supports this really well out of the box (and michaeltwofish is currently writing a lithium plugin to allow the command line testing to output to hudson). Our plan was to use selenium for the acceptance tests (read BDD), but as selenium needs to run a firefox executable, this can't work (easily¹) on the vm. So we've now got webrat (and cuke) running instead.

Most of this post is taken from other sources. The first place to read is aslakhellesoy/cucumber/wiki/php. It's also well worth looking at chits: a real PHP application that uses cucumber/webrat. Also see Acceptance tests on a PHP project with the cucumber / webrat / selenium trio.

I repeated these procedures on darwin and centOS without any problems.

Installing ruby and gems

I downloaded and installed ruby 1.9.2 from source. This also installed the latest version of ruby gems.

$ ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.5.0]
$ gem -v
1.3.7

Installing required gems (cucumber and webrat)

These are the gems I installed:

$ gem install cucumber
$ gem install webrat
$ gem install mechanize
$ gem install rspec

Layout

You'll need to put your cuke and webrat files somewhere. Typical location is the app/tests/features directory. The feature files go in the top "features" directory:

+––– apps/tests/features/
     +–––feature1.feature
     +–––feature2.feature
     +––– step_definitions/
           +–––webrat_steps.rb
     +–––support/
           +–––env.rb
           +–––hooks.rb
           +–––paths.rb

Features

A feature could map to a high level user story (in the agile method), and be made up of a number of scenarios to be tested. The feature is executed by cucumber and the output will show whether your acceptance tests have passed or failed (or some other error has occurred).

There's plenty of information about how to write these feature files on the cucumber site.

Step Definitions

Each step of a scenario (within the feature file) needs a definition in code of what is to be executed. These steps go in the step_definitions/webrat_steps.rb file. Some of the steps defined here are "standard" eg:

Then /^I should see "(.*)"$/ do |text|
  assert !!(response_body =~ /#{Regexp.escape text}/m), response_body
end

which is used to check if a particular piece of text appears on the page.

See the webrat repo on github, as well as the cucumber wiki page on step definitions, but also take a look at the step definitions of the chits app as this has a lot more examples.²

Support Files

There are three support files. env.rb is used to setup the testing and code here is run before (and possibly after) every scenario. The paths.rb file is a convenient place for the URLs webrat will access. The hooks.rb isn't strictly necessary but if there is code that needs to run before (or after) specific scenarios, this is where it goes.

See the wiki page on using cucumber for PHP apps and the chits support files for examples.

Conclusion

In Part 2 I will talk about getting this to work on a lithium application, in Part 3 I will talk about using cucumber to drive selenium tests and in Part 4 I will talk about putting it under continuous integration with Hudson.

1. All we really need is a headless firefox executable for linux. There is one, we just haven't installed it on our vm yet. But the other big benefit of using webrat over selenium is that it has a much lighter resource footprint. ↩
2. Please note that the first line of this file (from the chits app on github) uses "re". I'm not sure if this is a ruby thing, but I had to change it to "require" to get it to work:

   require File.expand_path(File.join(File.dirname(__FILE__), "..", "support", "paths" ↩

We're using lithium (0.9.9 is available now although we're working against HEAD) for new projects at the company I work for (non-profit, in the educational sector, where we put a lot of tests/surveys etc. online).

One thing I've noticed is that we are doing a lot more pair programming. This is occurring naturally and I think a lot of it comes from the fact that Lithium is a really good framework with which to get work done.