Posted by James Mead
Wed, 25 Apr 2007 04:12:00 GMT
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…
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.
Tags dotnet, enterprise, java, job, london, rails, reevoo, ruby | no comments
Posted by James Mead
Fri, 22 Dec 2006 15:14:00 GMT
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.
Tags console, rails, ruby, yaml | no comments
Posted by James Mead
Sat, 02 Dec 2006 09:36:00 GMT
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.
Tags external, piston, plugin, rails, ruby, rubygem, svn, version | 1 comment
Posted by James Mead
Tue, 17 Oct 2006 13:19:00 GMT
It’s good to see that Chris on err.the_blog regards Mocha as part of his Rails Toolbox of “kickass open source software”.
Tags mocha, open, rails, ruby, software, source, toolbox | no comments
Posted by James Mead
Wed, 13 Sep 2006 09:55:00 GMT
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
Tags automation, conference, google, jmock, london, ltac, rails, railsconf, ruby, test | 1 comment
Posted by James Mead
Tue, 05 Sep 2006 06:35:00 GMT
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.
Tags mocha, mock, rails, ruby, test, thoughtworks, unit | 2 comments
Posted by James Mead
Tue, 05 Sep 2006 03:21:00 GMT
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.
Tags coverage, mocha, mock, patch, rails, stub, test | no comments
Posted by James Mead
Sun, 03 Sep 2006 18:20:00 GMT
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…
Tags coderay, highlight, jmock, mocha, mock, mocking, rails, ruby, stub, stubba, stubbing, syntax, test, testing | 4 comments
Posted by James Mead
Fri, 01 Sep 2006 14:07:00 GMT
I really must get round to writing some better documentation for Mocha, but in the meantime here’s a quickstart guide1.
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)
product = Product.new
product.expects(:save).returns(true)
assert product.save
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}
Product.any_instance.stubs(:name).returns('stubbed_name')
product = Product.new
assert_equal 'stubbed_name', product.name
object = mock()
object.expects(:expected_method).with(:p1, :p2).returns(:result)
assert_equal :result, object.expected_method(:p1, :p2)
object = stub(:method1 => :result1, :method2 => :result2)
assert_equal :result1, object.method1
assert_equal :result2, object.method2
1 I wrote these examples without checking them, so there may be some typos.
Tags class, instance, interception, mock, quickstart, rails, ruby, stub, testing, tutorial | 3 comments
Posted by James Mead
Fri, 01 Sep 2006 06:26:00 GMT
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.
Tags fixture, mocha, mock, mocking, rails, ruby, stub, stubbing, test, testing | 4 comments
