ryan / Fri, 23 Feb 2007 08:42:00 GMT
This article has moved over to our sister spin-off blog, RubyJudo, which focuses on more arcane technical topics than NotRocketSurgery.
NotRocketSurgery is Ryan Norbauer's blog about approaching life and business calmly, artfully, and sans bullshit.
I believe that the biggest problem in most domains of work is the need, born of insecurity, to pretend that anything is hard.
I believe in elegant approaches to improving one's work and life. And that the aesthetically pleasing path in business is also almost always the most pragmatic one.
If you're looking for web application development, visit my Boston-based Ruby on Rails consultancy, Norbauer Inc
Subscribe
Oh c’mon, Test::Unit is not that bad. RSpec only addresses the language of assertions (from what I’ve seen) which really is not a big issue to me. I don’t see Test::Unit as forcing you to do “mental backflips” in the least. As far as the English, use comments or say “def test_string_length_returns_the_number_of_characters_it_contains”... verbosity is not magic.
Other issues, like mocking and stubbing, however, are useful and critical to doing testing easily and quickly. I have begun to use Mocha but it can still be very difficult to limit a test’s scope as your code increases in complexity.
My point isn’t that Test::Unit is unusably awful or anything, merely that RSpec is a sufficient incremental improvement to nudge my lazy ass towards actually writing a test here or there.
Comments to make our code read like English? Like I said, we should set our expectations high. This is Ruby. :P
Mocking and stubbing are quite cool, and I’ve only recently started playing with them. But they are really only ancillary parts of RSpec—not central to all the hubbub about the framework, by most people’s writing anyway. Luke Redpath’s article, which seems to be the most linked-to tutorial on RSpec makes no mention of mocking or stubbing..
The next topic I’d like to write about is how you can use mocks/stubs, along with a few other RSpec tricks to almost entirely avoid having to write fixtures, which are an annoying and brittle mess to deal with if you have lots of models with multiple cascading associations.
Incidentaly, here is an interesting new development in RSpec core.
http://blog.davidchelimsky.net/articles/2007/02/21/generated-spec-names-keep-specs-dryer
RSpec will now write the name of the method for you based on your should statements. It’s much more DRY this way. You can always override with your own method name if you don’t like what ends up in your spec doc based on RSpec’s guesswork.
IMO it’s a brilliant way to learn Ruby/Rails from any of the available books. Just grab the code which accompanies the book, make a new rails project, put the code inside. And start to write specs/tests as you read the book. Discover the code and eventually language/framework itself as rocket surgeries do! :) P.S. Great article, thx!