December 12, 2008

Posted by John

Tagged testing and thoughts

Older: Using Gmail to Send Email With Rails

Newer: Deploying Rails on Dreamhost with Passenger

When You Don't Know, Test

Two articles in one night! Wow, you are lucky, eh? Anyway, I figured the first post, on Gmail wouldn’t be as applicable for everyone, so I thought I would hit on something new I’ve been doing of late for the rest of you. What you ask? Well, lately, when I don’t know how something works or I’m not sure what the outcome of something is going to be, I run it quick in IRB or make a small test case for it.

IRB

If it is something small enough that I can run on one line, I’ll just open it up in IRB and see what happens. Take for example the other day. I was trying to remember how to use regular expression matches in the gsub replace string, so I fired up IRB and tried what I thought was right.

$ irb
>> </code><code class="ruby">'foobar'.gsub(/^foo(bar)/, '\1')</code><code>
=> "bar"

That quick, I knew that I had guessed right and could move on in the project I was working on. Sure, I could have just guessed inside my project, but I find more isolated examples like this outside of a project help cement things in my head better.

Test Case

Now for small things, IRB works great, but for larger things, I find it better to make a quick test case. The other day, I was wondering how capable Time#parse was so I created the following test case.

require 'test/unit'
require 'time'

class TestTimeParse < Test::Unit::TestCase
  def test_parsing_verbosely
    assert_equal(3, Time.parse('3am').hour)
    assert_equal(15, Time.parse('3pm').hour)
    assert_equal(3, Time.parse('3 am').hour)
    assert_equal(15, Time.parse('3 pm').hour)

    assert_equal(3, Time.parse('3a.m.').hour)
    assert_equal(15, Time.parse('3p.m.').hour)
    assert_equal(3, Time.parse('3 a.m.').hour)
    assert_equal(15, Time.parse('3 p.m.').hour)
    
    assert_equal(3, Time.parse('3AM').hour)
    assert_equal(15, Time.parse('3PM').hour)
    assert_equal(3, Time.parse('3 AM').hour)
    assert_equal(15, Time.parse('3 PM').hour)
    
    assert_equal(3, Time.parse('3A.M.').hour)
    assert_equal(15, Time.parse('3P.M.').hour)
    assert_equal(3, Time.parse('3 A.M.').hour)
    assert_equal(15, Time.parse('3 P.M.').hour)
  end
end

All 16 assertions passed and I had my answer. It only takes a second to create a new document in TextMate, require ‘test/unit’ and create a test case. I’ve started creating test cases like this for a lot of things.

Store the Test Cases

Not only do I create these test cases, but I also save them all in a directory. This means whenever I want to relearn something that I have most likely forgotten, I have a directory full of fun test cases to check out. Next time you think, “I wonder”, go ahead and try it out for yourself. I’m also curious what you do for things like this. Anyone else do something similar? Better?

9 Comments

  1. you’ve just tested Time.parse in YOUR app

  2. i am definitely using irb for all these small tests,
    but most of the time, making those ‘fun tests’ does not seem worthwhile,
    because in doubt ill never find them again…
    (i do not think/hope it was suggested that these fun tests should be kept in the app tests, just somewhere else)

  3. Jon Wood Jon Wood

    Dec 12, 2008

    V-t: I think you’re missing the point a bit here – they’re not tests that become a part of the applications test suite, it’s just a handy way to quickly verify that your assumptions about a particular library are correct.

  4. I do the same thing as far as little tests scripts, I have a “playground” directory littered with all manner of small experiments.

    As for irb, I really recommend the Utility Belt gem if you haven’t heard of that. It requires wirble, so you get the syntax highlighting and tab completion, along well as auto-indenting of blocks/methods. Plus some other more advanced bells and whistles of various usefulness.

  5. @V-t – Yep, the others are correct. I’m not talking about app tests. I’m more talking about a “playground” as Don mentioned.

  6. Hah! Cool, yep I do this very same thing. Love IRB (and Utility Belt is must have .irbrc fu) but if you really want to test your assumptions a quick test case is the way to go. Been doing more benchmark requires of late too.

    Good post John — wonder if a shared repo of these sorts of tests wouldn’t be a cool resource?

  7. It only takes a second to create a new document in TextMate, require ‘test/unit’ and create a test case.

    That’s so true. Especially if you know that typing “tc” and hitting tab gives you a skeleton.

    (It strikes me that it would be useful if TextMate supported “a tip a day” hooks in its bundles. There are so many features that I’ve only found out about after a long while, and presumably tons that I haven’t found yet.)

  8. David - Oh, wow. Overlooked that shortcut somehow. Thanks for the tip. I do use the @deft shortcut to quickly create a test method, but I was unaware of the tc shortcut. Very nice!

  9. Great article John. I wish I thought of this years ago.

    Keeping a library of tests to validate your understanding of a framework is a great way to learn the framework and at the same time, provide yourself with examples on how to use that framework correctly.

Sorry, comments are closed for this article to ease the burden of pruning spam.

About

Authored by John Nunemaker (Noo-neh-maker), a web developer and programmer who has fallen deeply in love with Ruby. More about John.

Syndication

Feed IconRailsTips Articles - An assortment of howto's and thoughts on Ruby and Rails.

Feed IconRails Quick Tips - Ruby and Rails related links.