What Is the Community-Preferred Ruby Unit Testing Framework

What is the community-preferred Ruby unit testing framework?

You can stick to Test::Unit or you can have nice extensions to it using Shoulda or some cool contexts using Context.

On the other side, if you prefer BDD then you can safely stick to RSpec.

As for for acceptance testing use Cucumber .

What's the most commonly used unit testing framework for different types of Ruby applications?

TestUnit is based on JUnit, and so there is port to most languages. This is probably the most ubiquitous.

Behavior driven testing has yielded tools like RSpec, and it seems like right now that may be the most popular test framework in the ruby/rails world. (Here's a site that attempts to keep tabs on popularity: http://ruby-toolbox.com/categories/testing_frameworks.html)

Syntactically you will need to make a choice between those two big camps. Within them, there are lots of implementations, each with their own history, pluses and minuses. Even within the TestUnit world, you can grab "shoulda" and have much of what RSpec gives you. Confusing, eh?

Most of the tools are not explicitly tied to a framework and work fairly independently of Rails.

Is there a consensus about test frameworks for Ruby 1.9.x?

Is there consensus? I'd say not. There's a strong community voice for using TDD/BDD but even then it's not universal. The framework is probably less important than applying the practice in the first place.

I believe that minitest is the 1.9 replacement for Test::Unit, which only exists as a wrapper around the new library for backward compatibility. I'd guess that taking the minitest-specific route would be more forward-looking.

RSpec is a somewhat different take: less obviously infused by the "traditional" xUnit-influenced frameworks. It's worth spending some time with to see if you prefer it.

There's also Shoulda. although I don't know how tested it is on 1.9: it's more of a wrapper/extension for Test::Unit, so it'll probably work, though.

Of course the fun doesn't stop there: once you've chosen a test framework you're going to want a mocking engine of some kind. Or a data fixture replacement.

In all cases, I'd say any framework for which you can find evidence of regular updates, an open, populated community and an API you don't hate will do the job. It's unlikely that you're going to be shot down later for having made whatever choice you do.

Rspec vs. TestUnit

Both Test::Unit and Rspec are very nice solutions. As for me I prefer to use RSpec in my Rails project - because it has many automatic solutions like autotest, highlighting syntax, shortcut commands like rake spec and other stuff that make using test easer. But in my plain ruby scripts I use Test::Unit - it is very lightweight and staightforward when you don't need complex testing (integrational and others)

How to get started with unit testing in Rails?

Right now most people seem to be using Rspec for unit testing and Cucumber for integration testing. You can see a fairly recent poll here where 87% chose Rspec in a survey.

A great book for Rspec and Cucumber is The Rspec Book written by the current maintainer of Rspec. It goes over both Rspec and Cucumber.

Railscasts also has a few relevant screencasts. Cucmber1, Cucumber2

Many people seem to love Cucumber but it doesn't seem as useful if you don't have a client you're doing work for. Most of my projects are side projects I do myself so these days I'm looking into Steak instead of Cucumber. This will allow me to use Rspec for unit tests and Steak for integration tests and reduces some complexity/tedium that is introduced when using Cucumber.

People have said that it doesn't really matter which testing framework you pick, it's more important that you START TESTING. I agree with that but hopefully these resources will help you get started.

However, one thing you probably want to avoid from the very start are fixtures. Use factories instead and check out this Railscasts episode on it.

---

UPDATE: Steak is no longer necessary and the same functionality is baked into Rspec.

Testing tools available for Rails application

Definitely read the Rails guides on testing best practices; there's a ton of books, blog posts, and Youtube videos out there on how to test. But part of your question has been a particular pain point for me so I'll give a brief answer here too: Which of these complex tools are worth using, and for what kinds of tests?

The Rails community is huge on tests, but personally I think that it's possible to go too far, focus too much energy on your test suite at the expense of actually writing code. Some high-profile folks have even advocated that developers try out not writing tests once or twice, just so that we can get firsthand experience with the effect it has on our code quality, number of bugs, etc. (Spoiler: quality goes down, bugs go up, customer satisfaction goes down. But it's different for you to learn this firsthand than for me to just tell you.)

So my personal testing habits for Rails apps are:

• I prefer Minitest over Rspec. The former encourages plain, straightforward unit tests; the latter encourages verbose specs and a larger testing infrastructure. Minitest (or Rspec) is more or less "global" to your test suite, in that all of your specs will be written using that same framework. Which is good because there's less tools to manage and less to learn.
• FactoryGirl is useful in quickly setting up a specific database scenario for a given test. I use it in model, controller, and integration tests.
• Capybara is a framework for writing highly readable end-user acceptance / integration tests. It's appealing but it's easy to overuse, leading to verbose tests that get brittle and hard to maintain. I write (thorough) controller specs first, then write judicious integration tests afterwards.
• Cucumber is a layer on top of Capybara (for integration tests) or for any other kind of test; it lets you write out your tests in a human-readable format and forces you to think in terms of acceptance tests. But it gets easy to become too verbose, and on the tiny-team projects I've worked on so far, I haven't yet found it useful. I avoid it.
• Jasmine is like Rspec for Javascript: a language for writing readable and well-organized specs of your JS code. This may be useful if you have tons of custom JS code / logic, but I haven't yet used it or envied it.
• Model unit tests: I write at least one unit test for each custom method.
• Controller unit tests: I write at least one unit test for each logical path available to each controller action, and enable rendering views so the template generation gets exercised here too.
• Integration / acceptance tests: I go light on these, only adding very minimal paths to cover the essential use cases of the website. I find most bugs aren't caught at this level; the controller tests catch a lot more, since they render every single view template and execute every bit of model logic that the user can possibly trigger.

Is there a python equivalent for RSpec to do TDD?

The closest I have come to doing a brief google search was mamba + expects:

• mamba: https://github.com/nestorsalceda/mamba
• expects: https://github.com/jaimegildesagredo/expects

RSpec vs. Shoulda?

RSpec has a lot of nice features, more than just the syntax too. I would recommend it over Shoulda.

Even Thoughtbot, the authors of Shoulda, are using RSpec now. Shoulda now works as an RSpec plugin and it provides a number of useful matchers.

---

Related Topics