Posted by Jason Rudolph on 8th February 2008
Believe it or not, there are still at least a few of us crazy hold-outs that still haven’t imbibed the increasingly ubiquitous RSpec Kool-Aid. And for the folks in this crowd that still want BDD-style testing, it’s test-spec and test/spec/rails all the way. So when I recently needed a means for validating that a nontrivial route landed in the right controller/action, I naturally went looking for the test/spec/rails equivalent of #assert_recognizes. When I saw that it was nowhere to be found, I knew I’d found another task for Open Source Fridays (er, the first half hour of an Open Source Friday). And thanks to Matthew Bass’s uncanny responsiveness in applying the patch that Rob Sanheim and I submitted, test/spec/rails now offers some handy new specs for testing your routes.
assert_generates => should.route_to
Where you’d use #assert_generates in traditional Rails + test/unit, test/spec/rails now supports #route_to as a more spec-flavored alternative. For example, to verify that a given set of URL options routes to the expected path…
assert_generates "/users/1", :controller => "users", :action => "show", :id => "1"
becomes
{:controller => "users", :action => "show", :id => "1"}.should.route_to "/users/1"
assert_recognizes => should.route_from
And where our ancestors once used #assert_recognizes, test/spec/rails now offers #you_bettuh_recognize#route_from. “An example would be nice”, you say? Well, to perform essentially the inverse of the above test…
assert_recognizes({:controller => "users", :action => "show", :id => "1"}, {:path => "/users/1", :method => :get})
becomes
{:path => "/users/1", :method => :get}.should.route_from :controller => "users", :action => "show", :id =>"1"
- - -
The rdoc offers additional examples, and check out the test/spec/rails README for more mappings from old-school test/unit assertions to test/spec/rails equivalents.
Tags: Rails, Ruby, Testing | No Comments »
Posted by Jason Rudolph on 20th December 2007
The Groovy community’s been busy rolling out a steady stream of holiday goodness for the Java developers of the world: Groovy 1.5 was just released, Grails 1.0 RC3 is out, and now the Prags are prepping two new Groovy books for early next year. And to top things off, the folks behind NFJS are hosting a three-day conference with Groovy and Grails experts from all over the world.
The inaugural 2G Experience will take place February 21-23 in Reston, VA, and the agenda is slam-packed! BDD with Andy Glover. DSLs with Venkat Subramaniam. Google Maps with Scott Davis. Metaprogramming with Jeff Brown. A can’t-miss JRuby/Groovy smackdown with Neal Ford. A Grails keynote with Graeme Rocher. The list goes on…
I’ll be presenting sessions on Going Further with Grails and Bending GORM: 5-minute Techniques for Enterprise Integration. And to close out the conference, Relevance’s Refactotum series will make its Groovy/Grails debut. I’m teaming up with Scott Davis and Venkat Subramaniam (and any stray Groovy/Grails devs that happen to wander nearby) to host this hands-on workshop helping attendees make their mark on the Groovy and Grails revolution.
Refactotum: Groovy/Grails (3-hour workshop)
Contributing to open source is great for your career. In a few short hours, you can learn, teach, promote your skills, and improve the quality of the community. In this unique workshop, we will show you how, by doing it. Using Grails as an example, we’ll show you how to:
- download the source code
- build and run tests
- use Cobertura and code review to find problem areas
- refactor some code
- create and submit a patch
Take this opportunity to begin contributing to Groovy, Grails, or any other open source project that interests you. Experts from the Groovy and Grails community will be on hand to help you get started.
So is Groovy really “the next generation” of the Java language? Come decide for yourself. As for me, I couldn’t agree more.
Tags: Grails, Groovy, Java, Testing | No Comments »
Posted by Jason Rudolph on 2nd November 2007
At RubyConf today, Stuart Halloway’s Refactotum workshop led to a brief but excellent discussion on the various approaches for testing private methods in Ruby. Ideas ranged from the typical solution of using #send (which won’t work once Ruby 1.9 lands) to Ryan Davis’s technique of simply making everything public. Evan Phoenix, on the other hand, suggested a solution that avoids the soon-to-be-brokeness of using #send while still allowing you to benefit from the inherent intent expressed by defining a method as private.
To demonstrate, let’s assume we have the following (admittedly contrived) class:
class Ninja
private
def kill(num_victims)
"#{num_victims} victims are no longer with us."
end
end
So how can we make sure that the private method is doing what we want, and do so while testing it in isolation? Why not temporarily define a new public method that simply passes through to our elusive private method?
require ‘test/unit’
class NinjaTest < Test::Unit::TestCase
def test_should_punish_sloppy_coders
@ninja = Ninja.new
def @ninja.flog_publicly(*args)
kill(*args)
end
assert_equal ‘3 victims are no longer with us.’, @ninja.flog_publicly(3)
end
end
Sweet!
src> ruby ninja.rb
Loaded suite ninja
Started
.
Finished in 0.000274 seconds.
1 tests, 1 assertions, 0 failures, 0 errors
Tags: Ruby, Testing | 3 Comments »
