BDD on Rails - Is the community more behind Shoulda or RSpec?
Asked Answered
T

8

7

For a new application I want to start dabbling in BDD and I'm trying to decide between using RSpec or Thoughtbot's Shoulda. I like the macros that Shoulda uses, and the fact that it doesn't seem to reinvent the way Ruby/Rails does testing, but simply provides an add-on. On the other hand, the macros seem like a bit too much "magic" instead of being explicit about what you're testing (however I know from dabbling that it's annoying to write a dozen "should be invalid without xxx" two-liners on a model). To be honest I find writing specifications/tests for models to be trivially and almost boringly easy, but I find writing them for controllers to be insanely difficult because I'm never sure exactly what I should be testing or how to write it.

I'm iffy on the subject of mocking and stubbing since I think they give you false assumptions (since you can just tell it to think it has whatever data you need or to pretend that Method X was called) and I know that RSpec makes heavy use of both of them. I like the documentation that RSPec produces but I'm creating an application for sale, not to give to a client so the pretty documentation isn't that useful. I like Cucumber but it seems like overkill (and yes I know it can be used with Shoulda).

At this point is the Rails community in favor of RSpec or Shoulda?

Trundle answered 19/10, 2009 at 12:38 Comment(0)
D
2

The rails community is in favor of both RSpec and Shoulda. It depends of the developer. If you prefer Shoulda, use it.
If you prefer RSpec, use it ;)

They're both different library with a similar goal. It doesn't mean every developer has to be for or against it. It only means that you can use either of them.

It's up to you to make your choice depending of your preferences (and the other developers you're working with).

Disclosure answered 19/10, 2009 at 12:38 Comment(0)
D
3

Regarding mocks and stubs (and fakes, doubles and whatnot) - when you're testing at the unit level, either with TDD or after the fact, the whole point is telling it to think it has the data you need, using a Stub. And you write a test for the real object to ensure that it actually produces that data. The intent is to check the internal behaviour of the class under test, not that its upstream connections are behaving properly. That's at the unit level - you will test the end-to-end behaviour in your integration or feature/story/acceptance tests (or whatever flavour of higher-level test name you prefer).

A mock object is, to my mind, more about the downstream - you want to check that the class under test has made the appropriate call - you're not concerned that anything actually happens, just that the right method was called with the right arguments. Mocks are really good for that. Rspec has its own mocking framework, but Mocha and FlexMock are also widely used.

There's been a lot of discussion/explanation/debate/flame-warring about nomenclature here, BTW. Martin Fowler (who is better-qualified than most to pronounce on the subject) wrote a seminal blog post to clarify it and I think it makes sense. Here's another article, with a few examples.

Dordrecht answered 19/10, 2009 at 12:38 Comment(0)
D
2

The rails community is in favor of both RSpec and Shoulda. It depends of the developer. If you prefer Shoulda, use it.
If you prefer RSpec, use it ;)

They're both different library with a similar goal. It doesn't mean every developer has to be for or against it. It only means that you can use either of them.

It's up to you to make your choice depending of your preferences (and the other developers you're working with).

Disclosure answered 19/10, 2009 at 12:38 Comment(0)
S
1

I use Shoulda matchers with RSpec. Best of both worlds: big community behind RSpec, fast development and lots of coverage with Shoulda matchers.

Statism answered 19/10, 2009 at 12:38 Comment(0)
F
1

You can use shoulda macros in RSpec. It is definitely less common, but a great option: http://robots.thoughtbot.com/post/159805987/speculating-with-shoulda.

But as Radar says, ultimately you should try them different libraries and decide.

Forgot answered 19/10, 2009 at 12:38 Comment(0)
P
0

A lot of the Rails developers out in the world use RSpec, and some of those use Shoulda. DHH, the lead developer of Rails prefers Test::Unit and Minitest. Thoughbot's Shoulda builds on both Test::Unit (And of course Minitest) and RSpec.

Ultimately, as a Rails Hotline volunteer, you'll get more community support out of RSpec and there are a ton of additional gems out there specifically for improving RSpec. With that said Minitest and Test::Unite are core to Ruby.

[OPINION] I tend to use RSpec if the software requires a "behavior flow" and Minitest if it requires pure unit functionality (mostly because Minitest's benchmark library is really simple).

Publius answered 19/10, 2009 at 12:38 Comment(0)
K
0

My current stack of testing tools is:

  • Steak for acceptance testing
  • Capybara for Browser simulation with drivers: Selenium & Akephalos
  • Machinist for stubs
  • Rspec for unit testing
Khudari answered 19/10, 2009 at 12:38 Comment(0)
W
0

As far as i can tell, since you mention BDD, there seems to be a more natural match between cucumber and RSpec. The thing i like most about shoulda are its validation-macro's. There are two options to solve that in RSpec:

  1. use the shoulda macro's in RSpec, a great option, answered before
  2. use rspec-validations-expectations plugin, small and hardly known, but which fixes just that (easy ActiveRecord validations testing).

You should definitely go with which library feels most natural to you (how tests are expressed). For me, with the previously mentioned options, it was easier to discard the shoulda option (on its own at least), and i went for rspec and cucumber.

Winston answered 19/10, 2009 at 12:38 Comment(0)
S
0

Shoulda watchers: 758.

RSpec watchers: 1279.

Ultimately, it's up to you to decide which one you prefer.

Sortie answered 19/10, 2009 at 12:38 Comment(1)
These snapshot numbers mean nothing without seeing the trends behind them.Titi

© 2022 - 2024 — McMap. All rights reserved.