Floehopper

ActiveRecord Model Class Name Clash

2009-11-02T16:21:44+00:00

I’ve just spent way too long trying to work out why the validation callbacks were getting called twice on one of my ActiveRecord models. I thought I’d write this up in case it saves someone else some pain.

In the end, I narrowed the problem down to the name of the model class which is Sync. I should’ve thought of this sooner, but it turns out there is a Ruby standard library class called Sync. I haven’t delved any further into why validation was being called twice. As far as I’m concerned, once you re-open an existing Ruby class like this, it makes sense that all bets are off.

However, I am a bit confused why the original Sync model class definition didn’t give a “superclass mismatch” TypeError, which is what happens if I do :-

  script/runner "class Sync < ActiveRecord::Base; end"

It must be a load order issue, since if I put the class definition in a file in app/models, I don’t see the TypeError. It would’ve saved a lot of time if my Sync model class definition had failed fast in this way. I might see if there’s a way to make that happen.

Mocha NoMethodError / Load order since version 0.9.6

2009-09-18T11:35:40+00:00

There have been a number of load order issues since 0.9.6 was released for which I apologise.

The key message is that since 0.9.6, you must ensure that your test framework (Test::Unit or MiniTest) is loaded before Mocha is loaded, otherwise Mocha will not monkey-patch the test framework and calls to the Mocha API will result in NoMethodError.

I hope to write this up in more detail soon, but in the meantime here are a couple of useful links :-

Please contact us on the mailing list if you have any questions.

Mocha Release 0.9.8

2009-09-18T11:17:44+00:00

Release Notes

Fixed bug NameError raised when using Mocha as a Rails plug-in. Since 0.9.6 the Rails plugin has been broken. See bug report for details. You will need to explicitly load Mocha after the test framework has been loaded, e.g. by adding “require ‘mocha’” at the bottom of test/test_helper.rb.
Make Mocha::ParameterMatchers#regexp_matches, #includes, #has_value, #has_key more robust. Thanks to Sander Hartlage.
Allow passing a block to Mocha::Configuration methods to only change configuration for the duration of the block. Thanks to Dan Manges.
Fixed bug doc generation fails in 0.9.7 gem.
Remove rdoc template incorporating google analytics from source control. The file just needs to exist locally and be ignored by source control. This should stop the warning showing up on e.g. RunCodeRun build results.

Mocha Test Spies

2009-09-14T16:58:56+00:00

Introduction

Today I finally got round to looking at Joe Ferris’ Test Spies fork of Mocha. Joe explained how Test Spies work and why he thinks they are useful in Spy vs spy on the ThoughtBot blog. I apologise to Joe for not getting round to this sooner.

I have a number of hesitations about merging these changes into Mocha as they stand. My thinking hasn’t really crystallized, but in these situations I often find it’s useful to force myself to try and explain myself in writing. Hopefully it’ll also generate some feedback.

I’d like to thank Joe for taking the time to fork Mocha and add this functionality. I’m particularly grateful that he’s taken the trouble to write a bunch of high-level acceptance tests.

Concept

In this section I’ve tried to write up some comments on Joe’s blog post under roughly the same headings :-

Why would I let spies in my code?

Joe correctly points out that setting up expectations before exercising the object under test is a bit of a departure from the traditional Four-Phase Test regime. I can see how some people might see this as counter-intuitive, but it doesn’t seem particularly so to me. Also the idea of Expected Behaviour Specification (i.e. setting up expectations before the Exercise phase) has a couple of advantages :-

Using Test Spies, you have to (a) set up a stub so the mock object knows what value to return and (b) assert that the stubbed method was invoked the requisite number of times with the appropriate parameters. Whereas using Expected Behaviour Specification, these are combined into setting up an expectation on the mock object. I think this results in terser code with less duplication.
Using Expected Behaviour Specification means that the test can fail fast if an unexpected invocation is made against a mock object. Failing fast is generally a good idea, because you are more likely to be able to identify the root cause of the problem.

Sharing stubs in a context

describe PostsController, "on GET show" do
  before(:each) do
    @post = stub('a post', :to_param => '1')
    Post.stubs(:find => @post)

    get :show, :id => @post.to_param
  end

  it { should render_template(:show) }

  it "should find and assign the given post" do
    Post.should have_received(:find).with(@post.to_param)
    should assign_to(:post).with(@post)
  end
end

I’m going to struggle a bit when commenting on this code example for a couple of reasons :-

I dislike the use of setup methods (before in this RSpec example). I prefer to do my setup in-line in the test to make the test as independent and as explicit as possible. I particularly dislike exercising the object under test within the setup method. To me this seems like a more fundamental breakage of the Four-Phase Test concept.
In this example, I would not want to assert that Post.find has been called. Nat Pryce (one of the authors of jMock) has a rule of thumb that says: “stub queries and expect commands”. In this example, the call to Post.find is clearly a query, so I would just stub it. I think about it like this: (a) stubbing Post.find is setting up the environment and making the instance of Post available; (b) the assertion then checks that the instance of Post is assigned to the @post instance variable; (c) the combination of (a) and (b) is enough to tell me that the Post.find method has been called – where else would the controller have got the instance of Post from?

So I’m not convinced I would need Test Spies for this example.

Sharing stubs between tests

module PostHelpers
  def stub_post(post_attrs = {})
    post_attrs = {
      :to_param => '1',
      :published? => true,
      :title => 'a title'
    }.update(post_attrs)
    stub('a post', post_attrs)
  end

  def stub_post!(post_attrs = {})
    returning stub_post do |post|
      Post.stubs(:find => post)
    end
  end
end

describe PostsController do
  include PostHelpers
  it "should show a published post on GET show" do
    post = stub_post!
    get :show, :id => post.to_param
    Post.should have_received(:find).with(post.to_param)
    post.should have_received(:published?)
    should render_template(:show)
    should assign_to(:post).with(post)
  end
end

describe "/posts/show" do
  include PostHelpers
  it "should display a post" do
    assigns[:post] = stub_post
    render '/posts/show'
    template.should have_tag('h1', assigns[:post].title)
  end
end

In this example, as above, I would stub the call to Post.find rather than expect it.
I’d also prefer to use a real Post instance rather than a stub object. I’d use some kind of Test Data Builder like factory_girl to remove any duplication rather than methods like those in the PostHelpers module. While these ActiveRecord objects aren’t strictly Value Objects, I can’t help but think that this quote from Nat Pryce is relevant :-

Some languages might allow you to stub a value, but what’s the point? It is easier and less error prone to use the real type. If it’s not easier to use the real type then, I think, you should investigate why. What can you do to make the value type easier to use?

Steve Freeman makes a similar point in Test Smell: Everything is mocked.

Reusable matchers and assertions

# post.class.should have_received(:find).with(post.to_param)
should find(post)
# Post.should have_received(:new).with(post_attrs)
should build(Post, post_attrs)
# Post.should have_received(:new).with(post_attrs)
# post.should have_received(:save)
should build_and_save(Post, post_attrs)

I’m not convinced that extracting the assertion part of an expectation is sensible, because it’ll always need to be used in conjunction with the stub part of the same expectation.

Syntax

I think the suggested syntax extension is inconsistent with the existing Mocha API and a little clunky. See James Rosen’s comment on the mailing list. Looking at the following examples given in the documentation :-

  assert_received(mock, :to_s)
  assert_received(Radio, :new) {|expect| expect.with(1041) }
  assert_received(radio, :volume) {|expect| expect.with(11).twice }

I think I’d prefer to see something like :-

  assert_that mock.received(:to_s)
  assert_that Radio.received(:new).with(1041)
  assert_that radio.received(:volume).with(11).twice

Or something like :-

  mock.assert_received(:to_s)
  Radio.assert_received(:new).with(1041)
  radio.assert_received(:volume).with(11).twice

Note that I haven’t completely thought through the implementation implications of these suggestions i.e. whether they are even possible!

Implementation

The code looks good and, since Joe has written acceptance tests, there shouldn’t be too much difficulty in doing a bit of refactoring. I like the idea of introducing a model for an Invocation , but I think the Invocation instances should be stored by the relevant Mock instance rather than the Mockery. Similarly I’d push more of the logic in the HaveReceived class into relevant objects. And I’d like to avoid having to make Expectation#invocation_count writeable.

One slight concern is what happens if someone mixes up Expected Behaviour Specification expectations with Test Spies stubs and assertions? I’d probably at least want some acceptance tests to convince me that there are no complications on this front.

Conclusion

I’m sure that some people find the changes useful, but I’m not yet convinced I want to merge the Test Spies changes into Mocha. Please feel free to try and convince me, either here in the comments or in the mailing list thread.

Mocha Release 0.9.7

2009-07-01T11:52:49+00:00

Release Notes

Although I had provided a deprecation warning for people using the now renamed Mocha::Standalone, I had assumed people wouldn’t be explicitly loading the mocha/standalone.rb file. It turns out this assumption was incorrect at least in the case of RSpec. This is now fixed.

Mocha Release 0.9.6

2009-06-29T16:29:54+00:00

Release Notes

Version 2.0.1 of the test-unit gem introduced a private run_test method on TestCase which clashed with the public TestRunner#run_test method. So this latter method has been renamed to run_as_test.
Stop requiring rubygems – this should be an environmental choice for the user. This describes why requiring rubygems in your library code is a bad idea.
It seems like overkill to vendorize coderay and meta_project when they’re only needed to generate the examples for documentation and for publishing files on RubyForge. So I’m removing them and installing them locally as gems when I need them.
Added support for test-unit gem (version >= 2.0). Note that as with other versions of Test::Unit I’m completely replacing the TestCase#run method. Unfortunately in version 2.0.0 this method differs slightly from the same method in version 2.0.1 & 2.0.2, so we have to provide different implementations to ensure that the internal working of Test::Unit are not compromised by Mocha. Note also that unless the test-unit gem is loaded, requiring 'test/unit' leads to a mixture of standard library and gem classes being loaded causing errors. To avoid a dependency on rubygems, the gem is loaded only if MOCHA_OPTIONS is set to use_test_unit_gem – this option is only intended for use in running Mocha’s own tests. It might be worthwhile to create a shim gem like minitest_tu_shim to allow the test-unit gem to completely replace the standard library, but that’s a job for another day. My previous article on Test::Unit and MiniTest explains how the minitest-tu-shim works. The changes in the Rakefile are to make the default task run with the test-unit gem (version >= 2.0).
Renamed Mocha::Standalone to Mocha::API to better reflect its purpose. Added a deprecation warning for those who are referencing Mocha::Standalone.
Fix exception raised by HasEntry#matches? when first parameter is not a Hash (thanks to Taylor Barstow).
Ken Collins reported that Mocha is always loading MiniTest if it is available and loading it causes some Rails/ActionPack tests to break. I’ve removed the loading of MiniTest, but this now means the user has to ensure that if they want to use MiniTest in conjunction with Mocha, he must load MiniTest before loading Mocha.
Implemented Bacon integration (thanks to Ubiratan Pires Alberton), but this was then removed after deciding only to maintain integration with Test::Unit and MiniTest which are both Ruby standard libraries. See mailing list message for details.
Don’t monkey-patch MiniTest if it’s already been monkey-patched by Mocha.
Fixed bug – MiniTest integration was counting ExpectationErrors as errors not failures.
Fixed bug – Some Bacon tests were failing in Ruby 1.9.1.
Chad Humphries pointed out that in Ruby 1.9.1, if you are not using Test::Unit or MiniTest, Mocha will attempt to load and monkey-patch Test::Unit. Mocha will now only monkey-patch Test::Unit and/or MiniTest if they have already been loaded. MiniTest tests will now run in both Ruby 1.8.6 (with MiniTest gem) and in Ruby 1.9.1 (with MiniTest standard library). See Lighthouse ticket.
Made Mocha compatible with minitest 1.4.0 and above (thanks to Denis Defreyne).

National Express East Coast Ticket Options

2009-03-16T12:55:33+00:00

Introduction

In the past, I’ve tended to buy Advance Single tickets for most of my journeys between Durham and London. This is usually the best option when booking a couple of months ahead, but when you have to book at shorter notice, I often overlook some of the return fares.

Despite the supposed simplification of UK train fares, it’s not straightforward to find all the relevant information in one place, so I thought I’d write it up here. I hope other people might find this useful, but please double-check with the NXEC website or a Travel Centre before spending any money.

Fares from Durham to London

Ticket Type	Cost
Super Off-Peak Return	105.00
Off-Peak Return	163.80
Business Carnet	239.40
Anytime Return	266.00
First Class Anytime Return	370.00

Super Off-Peak Return Conditions

Northbound

Valid on any train from London King’s Cross except those timed to depart before 0929 Monday-Friday and from 1457-1859 inclusive, Monday-Thursday and from 1457-1815 on Fridays.

On a weekday, this means you can travel on the following direct services, departing London: 0930, 1130, 1230 & 1430, 1830¹, 1900, 1930¹, 2000, 2100.

Southbound

Valid on any train timed to arrive in London King’s Cross 1117 or later, Monday-Friday.

On a weekday, this means you can travel on the 0845 departure from Durham or any later train.

Off-Peak Return Conditions

Northbound

Valid on any train from London King’s Cross except those timed to depart 0645-0815 inclusive, Monday-Friday. Outward portions also barred 1559-1745 inclusive, Monday-Friday.

On a weekday, this means you can travel on the following direct services, departing London: 0615, 0830, 0930, 1130, 1230 & 1430, 1530, 1820, 1830, 1900, 1930¹, 2000, 2100.

Southbound

Valid on any train timed to arrive in London King’s Cross 1020 or later, Monday-Friday.

On a weekday, this means you can travel on the 0804 departure from Durham or any later train.

Business Carnet

10 Anytime Return tickets for the price of 9.
To be used within a 3 month period.

References

¹ Fridays only

National Hack the Government Day

2009-03-08T11:06:53+00:00

I spent yesterday in the shiny new Guardian offices at Rewired State – National Hack the Government Day – which was a lot of fun, despite the early start. There was a really friendly atmosphere and lots of interesting projects going on.

ONS Graphs

I teamed up with Paul to work on some improvements for the Office for National Statistics website. We’d noticed that while there are many timeline datasets available on the site, the only way to view graphs of the data is to download a Windows application called Navidata. Although it’s free, this application is pretty clunky and hard to use and doesn’t generate very clear graphs. Also, rather obviously, it isn’t much use to Mac or Linux users.

Update: More about our hack from Paul – GreaseMonkey vs the ONS at Rewired State

So for the first part of our hack, in a fine example of post-modern programming, we decided to use JavaScript to generate a graph in the browser using the HTML table form of the data. Thanks to an article by Rebecca Murphey, we decided to use jQuery together with Rebecca’s graphTable jQuery plugin which uses the flot jQuery plugin to actually draw the graphs. We used the GreaseMonkey, the Firefox add-on, to write a little script to pull everything together.

`3335553400' could not be displayed because:
File does not exist: .

So now anyone can use this script to view graphs of ONS timeline datasets :-

Get Firefox
Install GreaseMonkey
Install ons_graphs.user.js
Browse to a timeline dataset, View Table, View Series, Add to Selection, Download then View On-Screen.

`3336023889' could not be displayed because:
File does not exist: .

ONS Navigation

For the second part of our hack, we wanted to make a better way of navigating to the datasets. The current system uses a series of forms in a wizard-like experience which is quite hard to understand. Also, because of the form submissions (i.e. HTTP POSTs) required to access the datasets, there are no permanent URLs available to navigate directly to a dataset. We decided to try to remedy this by using Mechanize to scrape the timeline data from the website and then build a simplified static website using only links (i.e. HTTP GETs). However, we hit a snag in automatically submitting the last form in the wizard and ran out of time. I might try and have a go at this in the future if I get time.

We did notice that this last form had a hidden field containing what appeared to by a SQL query, making it ripe for SQL injection attack, but fortunately we managed to restrain ourselves.

Thanks to Ben Dodson & Paul Battley for the photos.

Uninstalling gems from .gem directory

2009-02-16T15:56:48+00:00

I keep forgetting how to do this, so I thought I’d write myself some notes.

In a recent version, RubyGems changed it’s behaviour on gem install so that if it doesn’t have sufficient permission to install the gem files, it installs them in ~/.gem and generates a warning :-

  $ gem install <gem-name>
  WARNING:  Installing to ~/.gem since /usr/local/ruby-1.8.6-p287/lib/ruby/gems/1.8 and
    /usr/local/ruby-1.8.6-p287/bin aren't both writable.
  WARNING:  You don't have /Users/jamesmead/.gem/ruby/1.8/bin in your PATH,
    gem executables will not run.

Sometimes (e.g. when you forgot to prepend sudo) this isn’t what you want. However, it’s not obvious how to uninstall the gem again to correct your mistake :-

  $ gem uninstall <gem-name>
  ERROR:  While executing gem ... (Gem::InstallError)
    Unknown gem <gem-name> >= 0

To make this work, you need to specify the install-dir option :-

  $ gem uninstall <gem-name> --install-dir=~/.gem/ruby/1.8/
  Successfully uninstalled <gem-name>-x.y.z

Note that if you are using Ruby 1.9, it looks like the RubyGems directory path includes the point release version number e.g. 1.9.0 or 1.9.1.

Update: Prevention is better than cure. Coderr suggests protecting your ~/.gem directory.

Mocha Configuration

2009-02-09T11:40:00+00:00

Introduction

In his recent look at Mocha’s internals, Brian Guthrie mentioned that he hadn’t realised it was possible to configure Mocha to warn or disallow mocking of non-existent methods. So I thought it was time I explained Mocha’s configuration settings. These configuration settings are all somewhat experimental and feedback on their effectiveness would be welcome.

There are 3 levels for all of the existing conditions :-

  # default behaviour
  Mocha::Configuration.allow(condition)

  # warning is displayed when condition is met
  Mocha::Configuration.warn_when(condition)

  # error is raised when condition is met
  Mocha::Configuration.prevent(condition)

Stubbing a non-existent method

This is useful if you want to ensure that methods you’re mocking really exist. A common criticism of unit tests with mock objects is that such a test may (incorrectly) pass when an equivalent non-mocking test would (correctly) fail. While you should always have some integration tests, particularly for critical business functionality, this Mocha configuration setting should catch scenarios when mocked methods and real methods have become misaligned.

  Mocha::Configuration.prevent(:stubbing_non_existent_method)

  class Example
  end

  class ExampleTest < Test::Unit::TestCase
    def test_example
      example = Example.new
      example.stubs(:method_that_doesnt_exist)
      # => Mocha::StubbingError: stubbing non-existent method:
      # =>   #<Example:0x593760>.method_that_doesnt_exist
    end
  end

Stubbing a method unnecessarily

This is useful for identifying unused stubs. Unused stubs are often accidentally introduced when code is refactored.

  Mocha::Configuration.prevent(:stubbing_method_unnecessarily)

  class ExampleTest < Test::Unit::TestCase
    def test_example
      example = mock('example')
      example.stubs(:unused_stub)
      # => Mocha::StubbingError: stubbing method unnecessarily:
      # =>   #<Mock:example>.unused_stub(any_parameters)
    end
  end

Stubbing a non-public method

Many people think that it’s good practice only to mock public methods. This is one way to prevent your tests being too tightly coupled to the internal implementation of a class. Such tests tend to be very brittle and not much use when refactoring.

  Mocha::Configuration.prevent(:stubbing_non_public_method)

  class Example
    def internal_method; end
    private :internal_method
  end

  class ExampleTest < Test::Unit::TestCase
    def test_example
      example = Example.new
      example.stubs(:internal_method)
      # => Mocha::StubbingError: stubbing non-public method:
      # =>   #<Example:0x593530>.internal_method
    end
  end

Stubbing Method on Non-Mock Object

If you like the idea of mocking roles not objects and you don’t like stubbing concrete classes, this is the setting for you. However, while this restriction makes a lot of sense in Java with its explicit interfaces, it may be moot in Ruby where roles are probably best represented as Modules. Anyway that’s probably a discussion for another day.

  Mocha::Configuration.prevent(:stubbing_method_on_non_mock_object)

  class Example
    def example_method; end
  end

  class ExampleTest < Test::Unit::TestCase
    def test_example
      example = Example.new
      example.stubs(:example_method)
      # => Mocha::StubbingError: stubbing method on non-mock object:
      # =>   #<Example:0x593620>.example_method
    end
  end