Nexopia kindly donate space and Internet, and the turnout was good.  We ended up all fitting into one board room so it was a good opportunity to meet other Ruby enthusiasts face-to-face.

Introductions

The meetup started by going round the table to do some introductions.  Since this was our first meetup there were lots of new people to introduce.  All of the attendees with Twitter accounts were added to our Edmonton Rubyist list.  If you attended and aren’t on the list please DM @yegrb to get added.

Announcements

Once everyone was introduced we asked the room for any recent Ruby related news.

• Rails 3 Beta is out!
• Harmony lets you test your javascript in your Ruby tests.
• Yardstick Software is looking for Rails developers.  DM @DonRiep for details.

Talks

Next came the speakers.  There was a range of topics, from intermediate to advanced but all really interesting and great to see coming from local developers.

• “Fly Your HTTP To The Moon” by Daniel (@darkhelmetlive)
• “So You Built The Next FarmVille (Riak with Ruby)” by Mark (@MarkBennett)
• “oncloud.org” by Graham (@stormbrew)
• “What’s your stack?” by Mike (@mikedeering)
  • Editors –> TextMate, emacs, vim
  • Testing –> shoulda, remarkable, rspec, ZenTest, factorygirl, machinist, Faker
  • Continous Integration –> cruisecontrol.rb, integrity
  • Metrics –> flog, MetricFu, http://getcaliper.com/
  • Database –> MySQL (on strict mode), slim_scrooge, Riak
  • View –> Blueprint, compass, HAML, SASS, Typekit, cufon
  • Deployment –> rake, asset_packeger, jammit
  • Stacks –> Rails, Sinatra, Rack, coderack.org
  • Distribution –> bundler, rubygems
  • Hosting –> Heroku, oncloud.org
  • Authentication –> authlogic
  • Comet –> juggernaut, node.js, tornado
  • Issue Tracking –> lighthouse, fogbugs, redmine, Trac
  • Misc –> staticmatic, serve

Feedback

We got a little feedback from attendees last night, but we will be putting together a quick survey to see what people thought of our first meetup.  Watch @yegrb for the link.

There was some interest from specific attendees in getting together to hack on a website for the meetups.  If you’re interested in helping out ping @yegrb on Twitter.

Wrap Up

The meetup finished up a little before 9:00 when everyone cleared out of the offices and some people headed over to Pub 1905.

Overall, the meetup was a great success.  We had lots of people who weren’t able to make it out this time, and there are already people talking about what to do at the next meetup.  The plan is to hold another meetup in about a month, though the date and location are still TBD.

Thanks again to Nexopia for the space, all the speakers, and everyone who came out!

When we look at the responses it’s clear that  most people are interested in meeting once a month for lighting talks and informal hacking sessions, starting sometime in the next month.  There is also some interest in longer more formal talks and tutorials, so they’ll probably have a place in our meetups at some point too.

Based on these results we’re shooting to start meetings by the end of February and will have more details once a date and time are confirmed.  If you haven’t had a chance to answer the survey polling is still open.   Have your say at http://edmontonrb.org.

For the statistically inclined keep reading for all the results.  (These charts will update in real time.)

What format would you like to see the gatherings take on?

How often would you like to meet?

When would you like the meetings to start?

As long-distance doggy daddies we’ve both been thinking a lot about the welfare of our pet, and know that he’s been well taken care of. We also know that not all pets are as lucky as Bruno. The RSPCA helps thousands of animals in need every year, and we thought supporting it would be a great way to honour Bruno while we’re away.

If you’re interested in sponsoring me I’ve got a page setup at:

http://city2surf.everydayhero.com.au/mark_bennett

In this post we’ll digress a bit and write a command-line tool to monitor and explore the information Zeroconf broadcasts on your network.  This will give us some background for the next post when we modify our web server to list other servers of a similar kind running on your network.  If you’re already familiar with how to browse and retrieve information about Zeroconf services using DNSSD then you may want to skip ahead.

Before I get too carried away, there are just a few notes about the require statements I’ll use in my examples.  As with all Ruby Zeroconf clients I will by requiring the DNSSD library.  Older versions of DNSSD seem to have compatibility issues when running on Linux so I always require DNSSD 0.7.1 (the latest at the time of this writing.)

We’re now ready to start browsing the network for Zeroconf services.  DNSSD supports browsing the network using either a synchronous or asynchronous API.  The synchronous API is new in version 0.7.1 and has the disadvantage that using it locks up your main application thread while it searches the network.  I haven’t used it in my applications and will only be covering the asynchronous API in this tutorial.  See the DNSSD 0.7.1 rdoc for an example of using the synchronous browsing API.

DNSSD.browse() is the core function to understand when browsing the network using DNSSD.  Given a Zeroconf service type  DNSSD.browse() will provide a DNSSD::Reply to a block of code which will be called each time a service is identified on the network.  It also returns a reference to a DNSSD::Service object which can be used to control the and stop the browsing.

For example let’s look at the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

require 'rubygems'
gem 'dnssd', '0.7.1'
require 'dnssd'
 
# Browse the network for web servers (_http._tcp services)
puts "Scanning network for web servers"
service = DNSSD.browse('_http._tcp.') do |reply|
 puts "received: #{reply.inspect}"
end
 
# Catch the interrupt signal
interrupted = false
Signal.trap("INT") do
  interrupted = true
end
 
# Run until the application is interrupted
loop do
  if interrupted
    puts "Halting network scan"
    service.stop
    exit
  end
end

On line 7, we call DNSSD.browse() and get back a reference to the DNSSD::Service object we can use to control the browsing.  We pass into DNSSD.browse() the kind of Zeroconf service we’re looking for (_http._tcp) along with a block of code which will print out the details of each service we find.  Inside that block of code we can access the service details using the reply object which is an instance of DNSSD::Reply.

The rest of the code in this example just runs the application until the user presses CTRL+C which sends it an interrupt signal which will terminate the application.  The application clean-up is handled on lines 20-22.  Notice the call to service.stop on line 21.  This tells the DNSSD::Service we got back on line 7 to stop running as we’re done with it.

Save and run this code, then try running your strawberry ice cream web service from the previous post at the same time in another window. You should see a message like:

received: #<DNSSD::Reply Strawberry\032Ice\032Cream\032\0431._http._tcp.local>

If you stop the web service you’ll see the message:

received: #<DNSSD::Reply Strawberry\032Ice\032Cream\032\0431._http._tcp.local>

Huh? That’s not what we expected! Why do we see the web server again when it’s shutting down?

It turns out that Zeroconf services broadcast when registering and then again when shutting down.  We can use the DNSSD::Reply’s flags attribute to determine whether the service is being added or should be removed.  The flags attribute is an instance of DNSSD::Flags and provides details about the state of the Zeroconf service.  Let’s modify our code to print out the flags it receives with each broadcast:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

require 'rubygems'
gem 'dnssd', '0.7.1'
require 'dnssd'
 
# Browse the network for web servers (_http._tcp services)
puts "Scanning network for web servers"
service = DNSSD.browse('_http._tcp.') do |reply|
 puts "received: #{reply.inspect}"
 puts "\tflags: #{reply.flags.inspect}"
end
 
# Catch the interrupt signal
interrupted = false
Signal.trap("INT") do
  interrupted = true
end
 
# Run until the application is interrupted
loop do
  if interrupted
    puts "Halting network scan"
    service.stop
    exit
  end
end

Run this new code in one window and try starting and stopping your web server in another.  You should now see a message which looks like this when the web server starts:

received: #<DNSSD::Reply Strawberry\032Ice\032Cream\032\0431._http._tcp.local>
    flags: #<DNSSD::Flags add>

and like this when the web server stops:

received: #<DNSSD::Reply Strawberry\032Ice\032Cream\032\0431._http._tcp.local>
    flags: #<DNSSD::Flags>

As you can see new services have the DNSSD::Flags::Add constant set.  Services that are being shutdown don’t have any flags.

With this in mind let’s modify our code one more time to show when services are added and removed.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

require 'rubygems'
gem 'dnssd', '0.7.1'
require 'dnssd'
 
# Browse the network for web servers (_http._tcp services)
puts "Scanning network for web servers"
service = DNSSD.browse('_http._tcp.') do |reply|
  if (reply.flags == DNSSD::Flags::Add)
      puts "adding: #{reply.inspect}"
  else
      puts "removing: #{reply.inspect}"
  end
end
 
# Catch the interrupt signal
interrupted = false
Signal.trap("INT") do
  interrupted = true
end
 
# Run until the application is interrupted
loop do
  if interrupted
    puts "Halting network scan"
    service.stop
    exit
  end
end

Run this code again and try starting and stopping your web server.  Now instead of some cryptic flags you should see a friendly message indicating when services are being added and removed!

The last thing I’ll talk about in this post is how to resolve the the address of the web server from the DNSSD::Reply.  If you’ve read the DNSSD rdoc already you may have noticed that DNSSD::Reply has attributes we haven’t used yet.  The reason we haven’t used them is because most of them aren’t initialised when you get a reply back from the browse() method.  Instead the reply we get back has just enough information to tell us if the service is new, and for us to use the DNSSD.resolve() method to get all it’s details.

Like DNSSD.browse() the DNSSD.resolve() method is asynchronous and passes a DNSSD::Reply into a block when it’s done executing.  The DNSSD::Reply we get back from resolve() is fully-populated and gives us access to things like the target (host name) where the service is running.

Let’s look at a final example which will show us a complete example of how to browse for web services on your network using Ruby and Zeroconf. The changes happen on line’s 11-25. We’re now taking the reply from the DNSSD.browse() method and using it’s name, type, and domain to resolve the details of the service in a new thread. Since Thread#kill and timeout.rb are broken we’ll let the browsing thread sleep for a few seconds and then use the resolver service handle to stop the resolver whether it’s found any details or not.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

require 'rubygems'
gem 'dnssd', '0.7.1'
require 'dnssd'
 
# Browse the network for web servers (_http._tcp services)
puts "Scanning network for web servers"
service = DNSSD.browse('_http._tcp.') do |reply|
  if (reply.flags == DNSSD::Flags::Add)
    puts "adding: #{reply.inspect}"
 
    # Let's lookup the details
    resolver_service = DNSSD.resolve(reply.name, reply.type, reply.domain) do |resolved|
      puts "\tdomain = #{resolved.domain}"
      puts "\tflags = #{resolved.flags.inspect}"
      puts "\tfullname = #{resolved.fullname}"
      puts "\tinterface = #{resolved.interface}"
      puts "\tname = #{resolved.name}"
      puts "\tport = #{resolved.port}"
      puts "\tservice = #{resolved.service}"
      puts "\ttarget = #{resolved.target}"
      puts "\ttext_record = #{resolved.text_record.inspect}"
      puts "\ttype = #{resolved.type}"
    end
    sleep(2)
    resolver_service.stop
  else
      puts "removing: #{reply.inspect}"
  end
end
 
# Catch the interrupt signal
interrupted = false
Signal.trap("INT") do
  interrupted = true
end
 
# Run until the application is interrupted
loop do
  if interrupted
    puts "Halting network scan"
    service.stop
    exit
  end
end

And that’s it!  You’re using ruby and Zeroconf like a pro.  Let’s hope you remember all this because we’ll use it in the next post to find out what kinds of ice cream the other people on your network enjoy!

In this post I’ll put DNSSD to work and we’ll use it to register our web site on the network.

To begin let’s go back and look at my web site code:

require 'rubygems'
require 'sinatra'
 
get '/' do
 puts "I love Strawberry ice cream!"
end

You can run your Sinatra application by saving this file as sp1.rb typing:

ruby sp1.rb

By default Sinatra will run on port 4567. To specify your own port stop the web server by pressing CTRL+C and start it again using:

ruby sp1.rb -p 12345

This will start Sinatra on port 12345, but you can use any port you want.

Now that we know how to run Sinatra we need to register our service using Zeroconf.

I’ll begin by requiring DNSSD. I like to require a specific version since I’ve had trouble compiling older versions of the gem on Linux:

gem 'dnssd', '0.7.1'
require 'dnssd'

Now we’ll add some lines right before we start the Sinatra application to register the web server:

register_service =
  DNSSD.register("strawberry ice cream +1", "_http._tcp", nil, Sinatra::Application.port) do
    puts "* Registered the strawberry web server"
  end

It’s good form to keep a reference to the register service around so you can unregister it manually using:

register_service.stop

Normally you won’t need to worry about this since DNSSD will unregister the service automatically when the Sinatra application terminates and the register_service object is cleaned up.

The final code should look like this:

require 'rubygems'
require 'sinatra'
gem 'dnssd', '0.7.1'
require 'dnssd'
 
get '/' do
  "I love strawberry ice cream!"
end
 
register_service =
  DNSSD::register(
      "Strawberry Ice Cream +1",
      "_http._tcp.", nil,
      Sinatra::Application.port) do
    puts "* Registering the strawberry web server"
  end

If you’re on a Mac or a PC running Safari and you want to see the website on your browser, just open your Safari Preferences (Safair > Preferences) and then check off the Bonjour boxes under the Bookmarks preferences panel. Close the Preferences pane and you should see a Bonjour folder on your bookmarks bar with an entry for “strawberry ice cream +1″.

Non-Safari users on Ubuntu, Mac OS X, and Windows can follow the directions Andrew TJ’s site to install the BonjourFoxy Firefox addon which will show Zeroconf web servers on your network.

Original Source: http://andrew.tj.id.au/projects/bonjourfoxy/

And that’s it, you’re now sharing your love of strawberry ice cream with the whole network!

In my next post I’ll talk about how to write Ruby code to automatically discover and list other strawberry ice cream lovers on your network.

Strawberry ice cream has a bad rep.

It’s not as sexy as chocolate and not as safe as plain vanilla. Instead it’s immediately relegated to third place in most ice cream debates.

Not satisfied with this situation I did what any coder would do and created a web site to evangalize strawberry ice cream using Sinatra.

Sinatra is great platform for quickly creating and deploying web applications, and works well for this example since the whole web site can be created with the following lines of code:

require 'rubygems'
require 'sinatra'
 
get '/' do
  'I love Strawberry ice cream!'
end

Now that I’ve got it running though, I realised it’s not going to do me much good if no one can find it. I could email a link to everyone or post it on Facebook or Twitter, but I want something that will work automatically and even if I don’t have access to the Internet. You may laugh and wonder how often that will be a problem but it’s something I ran into just this past weekend while at RailsCamp5 in the middle of the Australian hills. Cut off from the rest of the world we had no Internet and no tools to publish the web site. Or did we?

Applications like iTunes and Safari are able to find other computers and the services they offer without using an Apple server or the Internet. To test this for yourself just try sharing your iTunes music library with someone else on your network. If you unplug the Internet from your router the computers can still see each other and still see each others shared music. But how do they do this?

The answer is a magically technology called Zeroconf.

Zeroconf

Zeroconf is a way for computers to find the names and addresses of the other machines on their network and to register the services they provide without using a central server. Zeroconf started life in the labs at Apple where it was originally called Rendezvous, until it was renamed Bonjour for copyright reasons. Apple originally released implementations of Bonjour for windows under a proprietary license which proved controvertial with the open source community.  This lead to the creation of the independent Avahi implementation which was released under a more liberal GPL license.  Since the creation of Avahi Apple has relicensed Bonjour under an Apache-style license, however Avahi remains the most popular implementation on most Linux distributions.  Interested readers should check out Zeroconf’s Wikipedia entry for all the dirt.

Zeroconf is a well supported technology and is available on Mac OS X, Windows, Linux. There’s even support for the iPhone and Android phones. It’s also got bindings or implementation written in C, C++, C#, Java, Python and Ruby. Neat, eh?

DNSSD

To unleash the power of Zeroconf in Ruby we’ll be using a ruby gem called DNSSD. This gem is a wrapper around Apple’s Bonjour library on Windows and Mac OS X. On Linux DNSSD wraps Avahi’s Bonjour compatibility layer. To develop using DNSSD you’ll need to make sure that you’ve installed these libraries or else DNSSD won’t compile. Windows and Mac users can download the required file from the Apple website. You’ll also need to install the developer tools on Mac OS X. I’d appreciate feedback from Windows users on what tools they’re using to develop with DNSSD.

Ubuntu users can install Avahi and it’s Bonjour compatibility layer by typing:

sudo apt-get install avahi-daemon avahi-utils libavahi-client-dev \
  libavahi-common-dev libavahi-compat-libdnssd-dev libnss-mdns \
  avahi-autoip

Download and install any dependencies these libraries require. If you haven’t already you’ll also need to grab the Ubuntu build tools:

sudo apt-get install build-essential

Once you’ve got the required Bonjour or Avahi libraries installed you can get DNSSD by running:

sudo gem install dnssd

Assuming everything works you’ll see the gem install build the native extensions, and then install the DNSSD documentation into rdoc and ri.  I’ve tested this with DNSSD 0.7.1 and found it to work on Linux however I have had problems compiling DNSSD 0.6.0 in the past.  If you see errors while compiling you should make sure your gem repository is pointing to the latest gem repository available on rubyforge.

If you’ve made it this far you’ve now got DNSSD installed.  It’s worth taking a few seconds to start up your gem rdoc server:

gem server

and then browsing the DNSSD documentation.  It’s a little outdated but most of the examples should work with only some minor modifcations.

In the next post we’ll put Zeroconf to use by using DNSSD to register our strawberry server on the network.

Drupal TDD

The first big news is that phpunit_setup.inc is now part of a new project called Drupal_TDD.  To quote our README file the project is,

“…designed to make Test Driven Development with Drupal easy and enjoyable.”

As part of this change the source code for phpunit_setup.inc has moved to GitHub.  This will allow us to collaborate more easily on phpunit_setup.inc in the future, and should make it easier for any readers hoping to give test driven development with Drupal a try.

Check out the project page for news and updates, or to download the latest version of phpunit_setup.inc.  You can also visit the Drupal TDD wiki for documentation and examples.

Good-bye Backports, Hello Automated Version Detection

In other news, I’ve also been busy refactoring code to integrate some thoughts and feedback I’ve received.  The main changes are:

1. Using phpunit_setup.inc in Drupal 5 now works just like using it on Drupal 6. You no longer need to include drupal6_backports.inc in your unit test files.  The same steps Pat outlines on his blog to use phpunit_setup.inc in Drupal 6 will now work with Drupal 5.  This also means you won’t need to change your tests when migrating between versions.
2. When running under Drupal 5 phpunit_setup.inc now creates the same database schema as running a fresh Drupal 5 install. Rather than backporting the Drupal 6 installation process to Drupal 5 which created tables you wouldn’t normally use in a Drupal 5 installation, phpunit_setup.inc now automatically detects the version of Drupal you’re using and runs the appropriate database installation procedure.

There are still more announcements on the way, but that’s all we can reveal right now.  Stay tuned for further developments!

The theme for this weeks PhotoFriday is, ‘Extreme Close-up‘.  This is as close as I would like to get to this fellow.

Inspired by the work of Pat Shaughnessy in a series of great articles he wrote on Test Driven Development (TDD) using Drupal (1, 2, 3, 4, 5, 6, 7, and 8) I was motivated to take his code and use it on my current Drupal project.

Pat’s Solution

Following the pattern of TDD established by Ruby on Rails, Pat introduced the use of a command-line unit testing framework (PHPUnit) and then works the reader through using it to develop a simple Drupal module.  Inevitably Pat reaches a point in his example where he must begin loading test data into the database if his code is to be tested properly.

He begins by experimenting with different techingues to stage and unstage data at the beginning of each unit test.  Perhaps inevitably he then run into problems when tests fail or interact with each other in unanticipated ways.  This is where he takes it to the next level.

First, he introduces a system to initialize a seperate test database at the start of each testing cycle.  This ensures that the test database is unaffected by the production data and can’t accidentally corrupt a production website.

Second, he runs each unit test in it’s own database transaction.  Transactions are a database tool which allow each database connection to work with it’s own unique snapshot of the database.  Any changes made to the database only appear on that connection until the transaction is committed to the database.  If the connection is closed the changes are never committed, and the connection has no permanent affect on the database.

Practically speaking transactions allow each test to load any data they require and make any changes to the database they need without needing to worry about cleaning up after them selves.  When the test is over the database rolls back the tests changes automatically and efficiently leaving a clean slate for the next unit test.

Pat wraps all of these changes up in a file called phpunit_setup.inc which you just just have to include at the start of your tests.  It expects that you’ve created a test database and a user who can access it, and entered the connection details into the list of database connection in Drupal.  (See his original post for the details.)

Not only is this solution easier to maintain than complex database snapshots and loading scripts, but it’s more performant.

Implementing TDD in Drupal 5

Now let’s bring this great code of Pat’s back into Drupal 5.  Let’s try running it like we would in Drupal 6 and see what happens:

$ phpunit TestDataExampleTest2 modules/tdd/TddTests.php
Fatal error: Call to undefined function drupal_install_system() in
/home/mark/Work/LitDistCo/litdistco-website/includes/phpunit_setup.inc on line 85

Hmm, that’s a problem.  A little digging in the Drupal 6 API documentation reveals that the drupal_install_system() function is new in Drupal 6 and isn’t present in Drupal 5.  As we’re not interested in waiting for the client to upgrade to Drupal 6, we’re going to backport it ourself!

Since we want to avoid modify Pat’s code as much as possible we’re going to create a new include file called drupal6_backports.inc.  This will contain comparable versions of the Drupal 6 functions, which provide the functionality neccesary to run Pat’s code.  Any of your Drupal 5 tests will need to include this file before you include phpunit_setup.inc.  The code looks like this:

# Include the functions from Drupal 6 neccesary to run phpunit_setup.inc
# REMOVE THIS INCLUDE ONCE YOU'VE UPGRADED TO DRUPAL 6
require_once('includes/drupal6_backports.inc');

Later on when the tests are running on Drupal 6 you can remove these includes.

To backport drupal_install_system() I began by looking at the the source code from the Drupal API documentation:

function drupal_install_system() {
  $system_path = dirname(drupal_get_filename('module', 'system', NULL));
  require_once './'. $system_path .'/system.install';
  module_invoke('system', 'install');
  $system_versions = drupal_get_schema_versions('system');
  $system_version = $system_versions ? max($system_versions) : SCHEMA_INSTALLED;
  db_query("INSERT INTO {system} (filename, name, type, owner, status, throttle, bootstrap, schema_version) VALUES('%s', '%s', '%s', '%s', %d, %d, %d, %d)", $system_path .'/system.module', 'system', 'module', '', 1, 0, 0, $system_version);
  // Now that we've installed things properly, bootstrap the full Drupal environment
  drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  module_rebuild_cache();
}

There don’t appear to be any new Drupal 6 functions in this code so I pasted it into drupal6_backports.inc as is and ran the unit tests again (remembering to add the line to include the backports mentioned above.)

$ phpunit TestDataExampleTest2 modules/tdd/TddTests.php
Fatal error: Call to undefined function default_profile_tasks() in
/home/mark/Work/LitDistCo/litdistco-website/includes/phpunit_setup.inc on line 88

Closer but it looks like we’re still missing something.  This time it’s the default_profile_tasks() function.  The  code from the Drupal 6 API documentation looks like this:

function default_profile_tasks(&$task, $url) {
 
  // Insert default user-defined node types into the database. For a complete
  // list of available node type attributes, refer to the node type API
  // documentation at: http://api.drupal.org/api/HEAD/function/hook_node_info.
  $types = array(
    array(
      'type' => 'page',
      'name' => st('Page'),
      'module' => 'node',
      'description' => st("A <em>page</em>, similar in form to a <em>story</em>, is a simple method for creating and displaying information that rarely changes, such as an \"About us\" section of a website. By default, a <em>page</em> entry does not allow visitor comments and is not featured on the site's initial home page."),
      'custom' => TRUE,
      'modified' => TRUE,
      'locked' => FALSE,
      'help' => '',
      'min_word_count' => '',
    ),
    array(
      'type' => 'story',
      'name' => st('Story'),
      'module' => 'node',
      'description' => st("A <em>story</em>, similar in form to a <em>page</em>, is ideal for creating and displaying content that informs or engages website visitors. Press releases, site announcements, and informal blog-like entries may all be created with a <em>story</em> entry. By default, a <em>story</em> entry is automatically featured on the site's initial home page, and provides the ability to post comments."),
      'custom' => TRUE,
      'modified' => TRUE,
      'locked' => FALSE,
      'help' => '',
      'min_word_count' => '',
    ),
  );
 
  foreach ($types as $type) {
    $type = (object) _node_type_set_defaults($type);
    node_type_save($type);
  }
 
  // Default page to not be promoted and have comments disabled.
  variable_set('node_options_page', array('status'));
  variable_set('comment_page', COMMENT_NODE_DISABLED);
 
  // Don't display date and author information for page nodes by default.
  $theme_settings = variable_get('theme_settings', array());
  $theme_settings['toggle_node_info_page'] = FALSE;
  variable_set('theme_settings', $theme_settings);
 
  // Update the menu router information.
  menu_rebuild();
}

We can repeat the same process as last time, taking the code from Drupal 6 and inserting it into drupal6_backports.inc then running the script again.

$ phpunit TestDataExampleTest2 modules/tdd/TddTests.php
 
Fatal error: Call to undefined function actions_synchronize() in
/home/mark/Work/LitDistCo/litdistco-website/includes/phpunit_setup.inc on line 90

I actually had to repeat this process twice more.  Once to add the actions_synchronize() function and again to add the _drupal_flush_css_js() function.  Each of these functions don’t really make sense in the context of Drupal 5 since one invokes actions only associated with Drupal 6 modules, and the other refreshes the random strings addes to CSS and javascript files which also doesn’t happen in Drupal 5.  This makes the code for both of them very easy to write:

function actions_synchronize() {
  # Just included for compatibility with newer Drupal version
  # Don't do anything
  return;
}
 
function  _drupal_flush_css_js() {
  # Just included for compatability with newer Drupal version
  # Don't do anything
  return;
}

By including drupal_6_backports.inc before phpunit_setup.inc at the top of the tests you can now execute them and they will begin to run. And run.  AND RUN!!!

What’s going on here?

Stepping into the phpunit_setup.inc script I can see the test database connection being opened.  It then calls this function:

function each_table($table_callback)
{
  global $db_url;
  $url = parse_url($db_url['test']);
  $database = substr($url['path'], 1);
  $result = db_query("SELECT table_name FROM information_schema.tables WHERE table_schema = '$database'");
  while ($table = db_result($result)) {
    $table_callback($table);
  }
}

This function call the $table_callback() function once for each table in the database, passing the table name in as a parameter.  If I inspect the value of $table however, I see that it’s simply passing the same $table name again and again.  Worse the expression:

$table = db_result($result)

never evaulates to false, so the code never exits.  So why is this happening?

It turns out the Drupal 6 and 7 redefine the db_result() function such that subsequent calls will step through the results of a query one row at a time.  In Drupal 5 db_result() takes a second optional parameter indicating which row of the results to read.  It’s defined like this:

function db_result($result, $row = 0)

So we’re not actually iterating through the results as expected but reading the first row of the result set again and again.  As a compromise I’ve changed Pat’s original function to:

function each_table($table_callback)
{
  global $db_url;
  $url = parse_url($db_url['test']);
  $database = substr($url['path'], 1);
  $result = db_query("SELECT table_name FROM information_schema.tables WHERE table_schema = '$database'");
  while ($table = db_fetch_array($result)) {
    $table_callback($table['table_name']);
  }
}

I’ve replaced the call to db_result() with one to db_fetch_array().  db_fetch_array() works the same in Drupal 6 as it does in Drupal 5 so this code will work fine in both versions.

Running it again we see that the tests run correctly:

$ phpunit TestDataExampleTest2 modules/tdd/TddTests.php
PHPUnit 3.2.16 by Sebastian Bergmann.
 
..
 
Time: 0 seconds
 
OK (2 tests)

My patch has been submitted back to Pat so that he’ll hopefully integrate them back into his post however for the time being I’ve packaged my changes into phpunit_setup_drupal5.inc.

And that’s it!  By following Pat’s instructions and including drupal_6_backports.inc and phpunit_setup_drupal5.inc in your tests you can perform full test driven development with test fixtures and an isolated test database in Drupal 5!  Now go try it for yourself!

UPDATE: I should point out that if you’re going to test your own modules, you need to edit the profiles/default/default.profile and include your modules in the default_profile_modules() function on line 11.