Thursday, August 16, 2007

RubyGems: Dust

I've often shown examples similar to the following snippet.

functional_tests do
test "given no name, when validated, then error is in the objects error collection" do
instance = Klass.new
instance.valid?
assert_equal "can't be empty", instance.errors.on(:name)
end
end

Forgetting the body of the test, the interesting thing about the snippet is that it's a grouping of tests that contains a single test. I prefer this syntax to defining a class that inherits from Test::Unit::TestCase and then defining tests by creating methods that start with "test_". All of the projects that I'm a part of use this syntax and I've yet to hear anyone say that they prefer the classic Test::Unit syntax.

Adding this to your project just got a bit easier. I extracted the core methods and created a new gem: Dust.

Dust gives you unit_tests, functional_tests, and test methods that can be used for defining tests. Dust also includes additional methods that can help enforce design decisions. For example, if you subscribe to the theory that setup and helper methods should be removed if possible, the Test::Unit::TestCase.disallow_setup! and Test::Unit::TestCase.disallow_helpers! should interest you.

9 comments:

  1. Thanks for posting this gem, Jay. I've been doing something similar in a few projects at work, but never bothered to package it up; we'd just copy the code over into a new project. blech!

    ReplyDelete
  2. Anonymous12:10 PM

    I've seen tests written this way in many examples on your blog, but I'm a bit confused as to why this is better than the old syntax.

    Is it primarily because you can identify the tests with arbitrary strings instead of trying to write titles like test_when_arg_is_nil_returns_nil? Just curious what the motivation was here.

    ReplyDelete
  3. Anonymous10:20 AM

    Ben, I find it easier to type and easier to read. I think you'd find you like it better also, if you tried it. However, just looking at the examples I can see how you aren't compelled to give it a shot.

    I believe that it's something you don't want to live without once you give it a try. Several others agree with me, and I haven't heard of anyone who prefers the traditional syntax after trying both.

    However, as always, YMMV. (and if it does, I'd like to know)

    Cheers, Jay

    ReplyDelete
  4. Jay, thanks for the explanation. I'm going to try using Dust for testing my newest project and see how it compares to the traditional syntax. Thanks for packaging it up in a gem!

    ReplyDelete
  5. Anonymous8:54 AM

    Hi Jay,
    What's the difference between functional_tests and unit_tests besides the name? From what I can see the only difference is the name of the module that will be created.

    ReplyDelete
  6. Anonymous6:17 PM

    Hi anonymous,
    There is no difference as far as the dust implementation is concerned, other than the module (as you noted).

    Here's some thoughts on splitting your test suite: http://blog.jayfields.com/2008/04/splitting-your-rails-test-suite.html

    Cheers, Jay

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. Is Dust replaced by expectations? If not, when do you use dust and when do you use expectations? I learn a lot from reading your blog postings, thanks a lot.

    ReplyDelete
  9. Anonymous12:30 PM

    Hi linh,

    Expectations replaces dust unit_tests. RSpec replaces dust functional_tests. I no longer use dust.

    Thanks for the kind words.

    Cheers, Jay

    ReplyDelete

Note: Only a member of this blog may post a comment.