Floehopper: Tag rails

Escape from the Enterprise - London Rails Jobs

James Mead — Wed, 25 Apr 2007 04:12:00 +0000

If you’re looking to escape the “Enterprise” world of Java and .NET for the shiny new world of Ruby on Rails, take a look at Ben’s blog post and 37Signals job advert.

Things are really starting to hot up here at Reevoo. When you’re in the middle of it all, it’s easy to forget the progress we’ve been making. In recent months, we’ve…

Secured funding from a very supportive VC.
Passed the 60 million mark on ratings and reviews served.
Added Woolworths among others to our already impressive list of partners.
Moved into a plush new office.
We’ve even hired a couple of ThoughtWorks developers for a month-long project.

I work with a talented and friendly bunch of developers…

We’re heavily into Test-Driven Development, Continuous Integration/Deployment and Open Source. It’s an exciting and fun place to work.

If you’re interested, send Ben (ben_at_reevoo_dot_com) your CV and mention you saw the job here.

Rails Console Shortcuts

James Mead — Fri, 22 Dec 2006 15:14:00 +0000

A couple of quick nuggets I picked up from Amy Hoy’s Secrets of the Rails Console Ninjas.

Firstly, the magic y method which dumps an object to YAML – much more readable than the standard inspect output.

>> y james
--- !ruby/object:User 
attributes: 
  firstname: James
  surname: Mead
  login: floehopper
new_record: true
=> nil

Secondly, clear your console using command + k (or ctrl + l for those on Windows)

Thanks Amy.

Rails Plugin Versioning

James Mead — Sat, 02 Dec 2006 09:36:00 +0000

A while ago Jay Fields described a number of ways to share Ruby code between projects and focussed on a useful technique which involves using RubyGems and unpacking them into your vendor directory. He also mentions the difficulties of versioning with Rails plugins.

We use a number of Rails plugins at Reevoo. Initially we used Subversion externals to include them in our projects, but for a while now we’ve been successfully using François Beausoleil’s Piston which is effectively an extension to Subversion. You end up with a copy of the plugin code in your own repository with the relevant revision number from the remote repository stored in your own Subversion metadata. Piston prevents you getting new versions of the plugin code every time you update (as you would with an svn:external) which can lead to unexpected changes, but makes it straightforward to update to a newer version of a plugin when you want.

You can find Piston here.

Keep Mocha in your Rails Toolbox

James Mead — Tue, 17 Oct 2006 13:19:00 +0000

It’s good to see that Chris on err.the_blog regards Mocha as part of his Rails Toolbox of “kickass open source software”.

Google Test Automation & RailsConf Europe

James Mead — Wed, 13 Sep 2006 09:55:00 +0000

Last week I was at Google’s inaugural London Test Automation Conference where I particularly enjoyed the talk by Adam Connors and Joe Walnes entitled “Does my button look big in this? Building Testable AJAX Applications”. It should be out on Google Video any day now (as are all the talks) and is well worth a look.

It was also good to hear from Nat Pryce and Steve Freeman about the new developments in JMock

Tomorrow I’m off to RailsConf Europe. Should be fun.

Updates:

the LTAC talk videos are here (thanks Ade).
the LTAC slides are here

ThoughtWorks team uses Mocha

James Mead — Tue, 05 Sep 2006 06:35:00 +0000

It’s good to see that a team from my old company has caught the Mocha bug…

Jay Fields describes how his team have been using Mocha to achieve Ruby on Rails Unit Testing in less than 1 second.

Ruby on Rails uses Mocha to test frameworks

James Mead — Tue, 05 Sep 2006 03:21:00 +0000

So thanks to Kev Clark’s interest and hard work, it looks like Mocha is being used to improve test coverage in some of the Rails frameworks – take a look at this patch.

New Mocha Docs

James Mead — Sun, 03 Sep 2006 18:20:00 +0000

Spurred on by Thorsten’s comment on Gluttonous’ blog and a mention of Mocha in the Top 5 Rails Stories of the Week, I’ve given the Mocha documentation a major overhaul.

Now the RDoc only shows the public API which should hopefully improve the signal-to-noise ratio and show how simple it is to use.

I’ve also had a play with CodeRay and generated syntax-highlighted examples.

Good general information on mocking…

Mocha Quickstart

James Mead — Fri, 01 Sep 2006 14:07:00 +0000

I really must get round to writing some better documentation for Mocha, but in the meantime here’s a quickstart guide¹.

Mocha adds a couple of new methods to all objects and classes – expects which sets up auto-verified expectations and stubs which stubs the method allowing any number of calls.

Both the expects and stubs methods actually return an expectation object. Relevant methods on an expectation are: at_least, at_least_once, never, raises, returns, times, with, yields which are hopefully fairly self-explanatory. If not there are some clues here

Mocking a class method

  product = Product.new
  Product.expects(:find).with(1).returns(product)
  assert_equal product, Product.find(1)

Mocking an instance method on a real object

  product = Product.new
  product.expects(:save).returns(true)
  assert product.save

Stubbing instance methods on real object

  prices = [stub(:pence => 1000), stub(:pence => 2000)]
  product = Product.new
  product.stubs(:prices).returns(prices)
  assert_equal [1000, 2000], product.prices.collect {|p| p.pence}

Stubbing an instance method on all instances of a class

  Product.any_instance.stubs(:name).returns('stubbed_name')
  product = Product.new
  assert_equal 'stubbed_name', product.name

Traditional mocking

  object = mock()
  object.expects(:expected_method).with(:p1, :p2).returns(:result)
  assert_equal :result, object.expected_method(:p1, :p2)

Shortcuts

  object = stub(:method1 => :result1, :method2 => :result2)
  assert_equal :result1, object.method1
  assert_equal :result2, object.method2

¹ I wrote these examples without checking them, so there may be some typos.

Injecting mocks (the Mocha way)

James Mead — Fri, 01 Sep 2006 06:26:00 +0000

I thought I’d compare and contrast the way Gluttonous was injecting mocks and how you can do it with Mocha.

Gluttonous’ way

  def test_process_exit
    delegate_methods_to_mock!(RailsFCGIHandler, :close_connection) do
      fcgi = flexmock()
      fcgi.should_receive(:close_connection)
      @handler.mock = fcgi
      @handler.stubs(:when_ready).returns(:exit)
      @handler.process!
    end
  end

Using Mocha

  def test_process_exit
    @handler.expects(:close_connection)
    @handler.stubs(:when_ready).returns(:exit)
    @handler.process!
  end

I think it’s a bit more readable and you don’t need the block construction which starts becoming a nuisance when you need to stub methods on multiple classes.