BuffaloFeeds » Ruby Inside » March 29, 2011

Feeds

105363 items (97572 unread) in 19 feeds

Friends (1021 unread)

• 2 Star (84 unread)
• John Carrino (12 unread)
• Comments for Josh the Outspoken (296 unread)
• Josh (34 unread)
• Planet Matt (595 unread)

Build (68091 unread)

• MAKE Magazine (20292 unread)
• Instructables.com (35006 unread)
• Hack A Day (5017 unread)
• Toolmonger (7776 unread)

Heads (716 unread)

• Exploration Through Example
• Paul Graham: Unofficial RSS Feed (113 unread)
• Stevey's Blog Rants (34 unread)
• Joel on Software (207 unread)
• Gibson Blog (239 unread)
• Adventures in Bloggery (123 unread)

News (27537 unread)

• Slashdot (25203 unread)
• Economist.com Global Agenda (1412 unread)
• Ruby Inside (922 unread)

fun (207 unread)

• Templar, Arizona (207 unread)

Ruby Inside (2 unread)

• 

  DHH Offended By RSpec, Says Test::Unit Is Just Great

  Posted: March 29th, 2011, 5:47pm MDT by Peter Cooper

  As an outspoken and opinionated guy, David Heinemeier Hansson (a.k.a. DHH), creator of Rails, is no stranger to a little bit of controversy. He frequently sets off interesting debates on Twitter from his @dhh account. The latest is, perhaps, the most involved yet and has been rattling on for a couple of hours today.

  So what's the beef? RSpec and Cucumber versus.. Test::Unit. It's no secret that DHH is a happy Test::Unit (and fixtures) user. Last October he tweeted:

  

  But here's what kicked off today's debate:

  
  
  
  

  Naturally, this brought a plethora of heckles, support, snark, and questions from DHH's followers, including:

  
  
  
  

  More specifically, though, DHH noted that this gist comparing some Test::Unit tests to RSpec triggered his statements.

  But back to the debate. JD Skinner asked: What testing tools do you use/recommend? DHH replied:

  

  Jeremy Welland asked: So why do you think RSpec/shoulda's approach is so popular? DHH's response:

  

  The debate rattled on for a few hours amongst various Ruby developers on Twitter (including Dave Thomas and Bryan TATFT Liles) and if you want to really dig into it, check out DHH's Twitter account and follow through some of the responses.

  I agree with DHH for the most part, though I use a mixture of RSpec, Test::Unit, and Minitest just to "keep my hand in." RSpec (and BDD) did seem to become "the way" to do testing in many circles, though, even when it didn't present any significant benefits. Cucumber, following on from RSpec, had a similar experience.

  This debate is important, though, not because DHH is right or wrong or because one testing system is better than another, but because it wipes away some of the lines in the sand and assumed "correct way" attitudes that exist. If you want to use Test::Unit, it's not "old and uncool" (yes, I've heard this) and you should get on with it (DHH is using it fer chrissakes.) Likewise, RSpec and Cucumber are not panaceas or catch all solutions but may have significant benefits you can take advantage of.

  Research your options and pick the tool that makes sense for you and your team. DHH has and he's sticking with Test::Unit. What's your take on it?

  Update: DHH recommends this post about testing which suggests you check out Test::Unit first before considering more extensive frameworks. A good read!

  
• 

  Watchr – More Than An Automated Test Runner

  Posted: March 29th, 2011, 2:56pm MDT by Joe Fiorini

  

  Watchr is a development tool that monitors a directory tree and triggers a user defined action (in Ruby) whenever an observed file is modified. Its most typical use is continuous testing, and as such it is a more flexible alternative to autotest. It is maintained by Martin Aumont and available on GitHub.

  Watchr works by allowing you to specify the path to the file or files you want to monitor. When the file is changed it executes whatever block of Ruby code you give it. As the README states its most common use case is as a replacement for autotest. After using Watchr for a couple years now, I have learned that it’s much more than that. For example, it has helped me automatically copy a setup script to a virtual machine while building it and to update large blocks of content in a database.

  How I Used Watchr to Automate Shopify Theme Development

  I recently started a Shopify project with a colleague (Shopify is a hosted platform for building ecommerce sites). Users can edit their store’s look and feel through a web-based admin interface. This may work for most shop owners, but I’ve grown accustomed to editing text in Vim and working at the command line. Fortunately, Shopify has a very nice API for uploading templates to your store. Watchr to the rescue! I fired up my editor and not long after I had a very helpful script:

  require 'shopify_api'
  
  watch('templates/.*\.liquid') do |match|
    puts "Updating #{match[0].inspect}..."
    upload_template(match.to_s)
  end
  
  def upload_template(file)
    ShopifyAPI::Base.site = "http://{key}:{secret}@{domain}.myshopify.com/admin/"
    asset = ShopifyAPI::Asset.find(file)
    asset.value = File.read(file)
    asset.save
  end
  

  With this script all I have to do is save the file I’m working on and Watchr uploads it to Shopify for me. How does it work? The directory structure on my file system mirrors Shopify’s template structure. All my script has to do is read the file and send the path and contents to the server. Watchr uses OSX’s native File System Events API to listen for changes to files matching the path string I pass into watch. When a matching file changes, it executes the block and hands in the path to the changed file (or files).

  These simple Watchr scripts have saved me time and, more importantly, frustration. With just a few lines of code I can automate away tedious parts of my day while following my preferred workflow and not compromise efficiency. Watchr is not just about running my tests, it’s about improving my workflow as much as possible.

  More Info

  Want some more information? Check out Watchr on Github, check out the docs, or read the wiki for some more examples. When you’re ready to get started run gem install watchr and write your first script.

  Editor’s note: I just noticed that Ric Roberts wrote Watchr: A Flexible, Generic Alternative to AutoTest for Ruby Inside back in 2009. You might find that post useful too.

  Joe is a Software Craftsman at LeanDog Software where he helps run their Ruby
  delivery practice on a boat in Cleveland, OH. He blogs about
  software-related topics at [blog.densitypop.com] and tweets as
  @joefiorini