RSpec has always rubbed me the wrong way too. i think my issue that it feels like a complete replacement for the testing built in that ive been using for the last several years, nd it just doesn’t feel as natural to put “spec” in all my commands.

Plus with the standard test unit i can be pretty lazy and generate alot of code i dont want to think about. if i generate a model or resource and forget to use the spec generator, im stuck cleaning up files and starting over. this way i can just go on without a second though.

We’re in the same boat. I use shoulda and mocha. I use selenium-client instead of webrat (lack of good javascript support), but have been eyeing the webrat selenium DSL.

I’m actually working on a mocha blog post (~ 2 weeks)

I just did a presentation on shoulda and mocha for SA Ruby (http://saruby.org). Albeit bad, but still introduced the group to the RSpec alternatives.

rSpec has been the obstacle to BDD/TDD for me for many months now. I know that as a solo practitioner that I want to use a test-driven approach, however, while I am able to pick up on the Cucumber portion of the process, the rSpec component just isn’t something I’ve been able to become comfortable with. Some people whom I respect have suggested Shoulda, and I’m going to give that a shot next time I get the urge to try testing. I’ll be watching to see if you decide to go forth with any form of how-to or tutorial =)

Yea, I totally agree. RSpec scarred be away from testing for some time because of several reasons, like clashes but most of all: feels like code smell. Right now I’m on Shoulda. No funky magic, just works as expected and easy on the eyes. Me myself associate Ruby with DRY code that still is self explainary (there are bad examples of course…), so I don’t see how anyone would even look at RSpec which is sort of like writing a thesis. burr Everything is about taste, but this still confuses me until this day. Now I know I’m not alone! ;)

I have never been an RSpec fan myself, use it when I have to. It just seem cumbersome, clunky, heavy, or whatever. I use Test::Unit or Shoulda and like those much better. Shoulda is something I would like to standardize on once I can have more say in what clients use.

So, I agree with you and have talked to other Rails devs that feel the same about RSpec, but use it because that is what people expect at this point.

I agree. I’m still more softie than rails, but i have this side project in rails. I just recently trashed the code to start over. It’s been a learning project for me and I wanted to have actual real tests. I use TDD with .Net so that was the natural way for me to test in rails. Trying to use rspec just felt awkward. I thought maybe it was my lack of experience, but sounds like maybe its a devs intuition.

..and it looks like several other agree with you too.

I’m using Shoulda, Webrat & Cucumber, and it just feels…clean. Never got the hang of RSpec.

Well… I guess is your background, same as mine. I was an early user of NUnit a years ago, the migration to ruby/rails unit test was ‘idiomatic’ to say so. As user of C# you move with that mentality; unit tests are the same in C# as in ruby, python, java, on and on. But there is no equivalent of BDD on C# nor java nor vb and that is why we’re not used to. Getting on BDD has been a difficult time for me, but think that adds great value from the businesss view, think about business processes not class behaviour.

I don’t like the RSpec DSL. It’s trying to be both Ruby and English at the same time, and the result is awkward.

Frankly, it is posts like these that fan the completely unnecessary fires for people who think that shoulda and rspec are competitors of some sort. Personally, I like the rspec syntax, I like the flow that it guides me through. However, that doesn’t mean shoulda is bad, just not for me. Steven Bristol and I had a nice discussion about this back in February at the RubyJAX meeting: http://vimeo.com/3296561

Using shoulda instead of rspec doesn’t make you a rebel, it doesn’t make you a genius or a moron. Rather than trying to start some sort of artificial flame war in your comments, why not focus on the ‘test’ vs ‘not test’ people.

RSpec vs Shoulda is like Ruby vs Python – a ridiculous argument. Instead, just be thankful that you have a tool that suits your style of thinking. You could be coding in Java, after all.

Great post! Finally somebody speaking their mind about using the mostly-native Rails testing environment.

Do you use autotest or anything similar?

I actually use rspec + mocha + cucumber now, and I don’t find RSpec to be clunky. I find how people use it to be clunky. THere are very few good examples on the web; the ones you do see make it look horrendous. I fought against rspec for a long time, and then a buddy showed me how to actually use it. I use it with mocha instead of rspec’s mocking framework, and occasionally I use the shoulda macros. I also like using rspec’s expectations with Cucumber

I find it quite nice, especially when working on a project I’ve stepped away from for a while. Seeing the names of my specs on the screen as they pass helps me remember what was going on. I like seeing those instead of the usual …........F…...F…....... output.

But I certainly think it’s best to know test::unit AND rspec well. It makes you more marketable and really, they’re not that different anymore.

I’m always willing to help anyone who has questions about rspec and workflow… I find I have a good perspective on it after resisting using it for so long.

A mocha ‘getting started’ article would be great! Or even a presentation at a ChicagoRuby meeting!

shoulda, factory_girl, webrat, dabbling with cucumber (am not entirely convinced yet, but that’s probably just my ignorance).

I also found rspec to be … “odd”, “clunky”, “hard to understand” when I started looking for more test tools for Rails … and when I found shoulda, I just stopped looking at rspec.

That’s not to say that I won’t ever take a second look at rspec, but for now, shoulda just fits better with my brain :-)

So your ideal would be to have this syntax:

Model.should_have(1).record

over this:

Model should have 1 record

Isn’t the point of a DSL to have something equally human and machine readable?

Ok, I’ll bite…

I love RSpec. I like being able to use strings that are easy to type, have spaces, punctuation, and mixed case letters to describe what I’m testing. I like using the should method on an object and the way it allows both nice linguistic flow, while allowing very powerful tests. Asserts always seemed to do things backwards to me. I speak English which means I am prone to like subject-verb-object constructs rather then verb-subject-object.

RSpec and Cucumber play nicely with each other. Webrat has a beautiful set of matchers (well nokogiri does anyway) that make like easy. I also like RSpecs output slightly more then test unit.

Regarding the RSpec DSL. It is not Gerkin and is not meant to be. You have to actually understand what the DSL is doing, and I know (because I RTFA) that this is distracting to some people. Once I understood how the DSL worked however, I found it wonderfully easy to use. I also find it acceptably useful for documenting code. Datamapper’s RSpec files are beautiful executable prose, but not a replacement for a decent manual.

I think we all agree that most of this is about ones tastes in programming. RSpec fits mine.

I don’t use RSpec either and instead use plain old test unit with mocha for unit tests although have recently been using cucumber for integration tests.

The workflow I tend to use is:

1. Write spec in Cucumber 2. Spec fails because method doesn’t exist or return correct value etc. 3. Write unit test 4. Unit test fails 5. Make unit test pass 6. Re-run specs 7. If specs still failing go to step 3 8. Specs pass 9. Go to step 1

One thing to note is that I never use mocks in integration tests as I want to test the full implementation where as in unit tests I mock anything that is not the method I am currently testing.

I just started testing, and I’m using shoulda and factorygirl, but I would love a tutorial on Mocha.

RSpec is nice if you want to learn the syntax. I CBA to learn the syntax, though, and I prefer to write plain Ruby instead of a DSL someone has invented.

August, I prefer to write my tests in binary instead a language someone has invented.

Corey makes a great point. Developers love their dichotomies, true or false.

I didn’t like RSpec “should” syntax at all at first, but after a few days with it that went away. What helps is if you limit your vocabulary with it then things don’t seem so much like magic. You can accomplish 90% of the stuff with “should ==”

Model.count.should == 1
person.name.should == "John" 

And other comparisons work (>=, <=, etc.). To me this is much prettier than assert_equal and the variants. Once you get comfortable with this, move to the boolean comparison which is nicer:

# instead of this...
user.admin?.should == true
# do this...
user.should be_admin

One great advantage is that once you learn this then “should_not” just negates the expression. Overall I’m much happier with this syntax over test/unit’s assertions.

That said, I do wish rspec as a whole was much lighter and simpler. I do prefer shoulda’s approach which is a thin layer around test/unit.

I was just about to say what Ryan Bates said. Actually, his first two examples are verbatim. I use “should ==” and “should !=” for nearly all of my examples (others being raises_error and contains and stuff like that). Note that =~ does not work, alas.

All that said, that’s not using RSpec in its true way. Really I could just use something like Jeremy McAnally’s matchy instead to get the same result without all of the “rest” of RSpec that I don’t use, but I feel that by using RSpec I’m unlikely to meet resistance or “reinvent the wheel” problems when I open source my specs.

Wow, it’s 2008 all over again. This post did not at all carry the message you seem to have wanted it to.

Instead of focussing on what tool to use, you should focus on people not writing tests at all. Personally, I don’t care what people use for testing, as long as they write tests, that’s what’s important to me. You’d be likely to hear me say “I don’t like it when people don’t writing tests” instead of “I don’t like tool xyz”.

The technique is way more important than the tool in this case, so yeah, this post is taking the direction of a lot of similar posts before it, to flame a tool. I use whatever feels right for a job, I like to play with the tools on the market, but what they all have in common is really what’s important: helping to write tests. I’ve used rspec, shoulda, test/unit, test/spec, and they all are fine with me, as long as I get the job done.

Focus on that, and you get a useful discussion going.

Hey guys,

I still am trying to become familiar with testing my apps, TDD / BDD. I agree with Mathias Meyer. The Problem on my side is, that to learn BDD / TDD is very hard, when you are comming from another plattform as Ruby / Rails. (comming from PHP)

Stepping into AJAX thing, often gives me the problem, that only like blog in 15min has not enough example, how to test, and best practices. I had to search a long time until a find an article NOT to use cucumber for these and those cases, such as testing authentication. Only looking for a scree. Like, Given I am logged in (step definition for example, only grabs for the “my account” link on the screen) When I add the movie “Star Trek IV” to my favourites then I should see “Star Trek IV” in my favourites list

We are developing multilanguage apps, with authentication / roles system, ajax stuff,... and for that… everywhere we run into difficulties with each of the system (lets say my favourites are named “Meine Favoriten” in german. so,... should I look for the German title or the english one? Do I have to test for both? With which one I begin, because, default is german. The examples often don’t go deep enough, and while figuraring out, how it works… I already built the whole app, or lets say, valueable results for the client. I know all the advantages, mostly, at the end, but for fast results, prototyping for the client… I seem to be to odd, to use it.

May be somebody should show me some things go get into it quickly. Instead, I am always trying to read and see screencasts, but the go not far enough for my needs, even the new Rspec book,... same problem all the time.

I would looove, if there would be more sophisticated screencasts, books… not only for beginner stuff, but semi-/ advanced stuff.

your a genius moron :)

Absolutely agreed. I’d had so many problems understanding how to do testing until I started using Shoulda. Now I have included webrat and factory_girl into my tool set.

Now… how to do continuous (autotest) javascript testing without Selenium?