On Wed, Apr 22, 2009 at 6:25 AM, Amos K. [email protected]
I wasn’t thinking about a gun. I was just wondering if there is some
underlying reason that I’m missing. Is there a background structure
that I’m not grasping? Is there a huge piece of functionality that
I’m missing? Is it faster than Test:Unit or Shoulda?
RSpec is not just about RSpec. It’s about BDD. It’s about encouraging
conversation about testing and looking at it in different ways. It’s
about illuminating the design, specification, collaboration and
documentation aspects of tests, and thinking of them as executable
examples of behaviour. You can do this all without RSpec, but RSpec
aims to help with innovations like:
- strings as example group names
- strings as example names
- pending examples
- nested groups for flexible organization
- should[_not] + matchers (inspired by hamcrest - a java library)
- one matcher supports both positive and negative expectations
- improved failure messages
- flexible/readable/customizable output formats
- built-in mocking framework
- plain text scenarios (now in Cucumber)
Specifically with Rails:
- component isolation. ZenTest offered separate test cases for
models/views/helpers/controllers before RSpec, and RSpec extended the
idea by allowing you to run controller examples with no dependency on
views and vice versa. Some folks get nervous with that sort of
isolation, but, generally, folks coming to Ruby from a background in
TDD with Java or .NET are all over it.
That’s not the full list, but a good overview. You can get some of
these things from other frameworks, but they almost all originated in
RSpec, which has been and will continue to be a center of innovation
in testing in Ruby since its creation in 2005.
To be clear, it is certainly not the only center of innovation.
Shoulda brought us macros, which are great, and we’ve made it easier
to write your own in RSpec, and now you can use shoulda matchers right
Micronaut adds a tagging system that allows you to group examples
together in different ways. This is definitely something we’ll be
adding to RSpec sooner or later.
Ryan D. and Eric H. continue to bring us game-changing testing
tools like autotest, heckle, flog, and flay.
RSpec has been around for nearly 4 years now. It has matured quite a
bit, and continues to do so. A twitter poll back in January suggests
that the majority of people doing testing in Ruby are using RSpec:
http://twtpoll.com/r/zhh2fm. Note that this poll pits RSpec against
all other frameworks and it still gets the majority. Polls are polls,
and in a community of over a million Ruby developers, it’s hard (for
me) to believe in the accuracy of a poll that 680ish ppl voted in. But
hey, that’s 360-ish ppl who are at least willing to say they use
rspec, so at least we know that much
The point being that with a lot of users comes a lot of mindshare. And
as RSpec continues to mature and become easier to contribute to, that
mindshare will grow. More and more extension libraries like
rspec_on_rails_on_crack and remarkable will emerge, and RSpec will get
better and better at supporting them. It won’t be long before “rspec
OR test/unit” becomes a false choice, and you’ll be able to seamlessly
use both in a unified suite. This is already largely the case, but it
will get better.
And let’s not forget http://rubyspec.org/
As for which tools to use, you should use the ones that make you happy
and make your job and life easier. If there is something that you like
about shoulda over rspec, then use shoulda. If prefer kickin’ it old
school, stick w/ test/unit or minitest. Regardless of the tools you
use, I’d recommend that you pay attention to RSpec and its community.
There is a lot of action here.
I’d also recommend that you read The RSpec Book. While the material in
the book is taught through RSpec, and much of the book is very
RSpec-specific, there is quite a bit of exploration of the process of
BDD that can be applied regardless of toolset. Not to mention
introduction to other tools like Cucumber, Webrat and Selenium.
Thanks for the thought provoking question. I’ve been involved with
RSpec since shortly after its creation in 2005, and I sometimes lose
sight of why I got into it and why I stay with it. This has been a
helpful reminder to me, and I hope you find my ramblings helpful to