Why repeat “should” over and over again in your specs? I prefer not to do this:

it "should throw an exception"
it "should not run if already running"
it "should prevent duplicate access"

You can practice TDD/BDD anywhere, whether or not you have a test framework available to you. For example, here’s a fragment of test.c from an Nginx module I wrote a few years ago:

Although I’ve been a believer in TDD/BDD for quite a while, rush was the first time I started a project and said, ok, THIS time I’m going to get really serious about it. My very first commit was a bunch of empty specs, and since then, I don’t think I’ve committed any new feature or even a bugfix without an accompanying spec.

How do you write a spec for this method without touching the filesystem or the user’s environment?

def authkey
  File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")
end

It’s no secret that I’m a big RSpec fan. Test::Unit feels pretty outdated these days, and none of the other frameworks can yet match the level of BDD goodness you get from RSpec. Throw in that it’s now a mature and stable library, and it seems like a sure bet for all your Ruby specing (or testing, if you like) needs.

Jay Fields posts about one expectation per spec, something that I generally agree with but often find hard to practice. I typically find myself with one mock and one assert per test, such as this example from the rush specs:

Specs should test assumptions, not methods.

How many specs should there be for each method? One per assumption. For example, this method:

I’ve been thinking about the “too much magic” problem of RSpec. There are two sides to this: too much magic in its internals, and too much magic in its matcher syntax. These are related. Shoulda and test_spec are popular because people like asserts. You never forget the syntax for assert_equals - at least, once you can remember the order the arguments go in (I always want to write the value first and the expected value second).

Specs (or tests) show that your code works in theory. A running app in production shows that your code works in practice.

Put `test_port_spec.rake` into lib/tasks, then run rake test:port:spec. It doesn’t delete the tests it ports; this way you get the joy of typing rm -rf test yourself.

Last week’s icanhasruby had a series of presentations themed around test setups. The main lesson I took away from this is that a single best-practice solution to test/behavior-driven development has not yet been found. But I get the sense that the community is zeroing in on some core concepts that may one day be as ubiquitous as MVC or the HTTP request/response cycle. Even more interesting is that this seems to be happening in a completely decentralized way. I’m not sure where the Rails core team stands, but, given that they are continuing to put work behind Test::Unit (which, as near as I can tell, has been unmaintained since 2003), they don’t seem to be participating much in this quiet BDD revolution. But part of the beauty of Rails and Ruby is that they don’t need to.