Skip to content
This repository has been archived by the owner on Apr 18, 2018. It is now read-only.

Why RSpec? #29

Closed
brandonweiss opened this issue Oct 31, 2012 · 7 comments
Closed

Why RSpec? #29

brandonweiss opened this issue Oct 31, 2012 · 7 comments

Comments

@brandonweiss
Copy link
Contributor

So I've been using curator for a while now, and I think it's great. I actually wrote my own library that implemented the repository pattern for mongo, and it looked surprisingly similar to curator; it's nice to know that we arrived in similar places.

That said, I had the opportunity to contribute back to curator recently for the first time on #27, and it wasn't a particularly good experience. I spent about an hour and half trying to read deeply nested contexts and figure out the proper way to write the tests, and about two minutes writing actual code to make those tests pass. Which is obviously a really bad ratio. Part of that is just that I'm not familiar with RSpec, and part of it was the way the app and tests were designed and written. I'd love to contribute more and improve things if I can, but realistically, if I'm really honest with myself, I'm not going to learn RSpec to do that; it's just more effort than it's worth.

I'm obviously personally not a fan of RSpec, although I'm trying to leave that opinion out of this. RSpec is just a tool, and using it is a personal choice. So if someone wants to build an application (closed source) and test it with RSpec, that's up to them and the people that work on it. However, I don't think using RSpec for an open source project objectively makes much sense. Open source projects should have as low a barrier to entry as possible, and Ruby already has a testing framework, MiniTest. It even has a spec style, which I use religiously. I've never met a Ruby programmer that didn't know test/unit or MiniTest, but there are plenty that don't know RSpec, and realistically, like me, they're probably not going to learn to use an entirely different tool just to contribute back a feature or fix. Whatever advantages RSpec has over MiniTest, if any, I can't imagine that they're so great that they merit increasing the barrier of entry to possible contribution.

Thoughts?

@pgr0ss
Copy link
Contributor

pgr0ss commented Nov 1, 2012

We use RSpec at Braintree. Althought MiniTest is part of ruby 1.9, it is not part of Ruby 1.8. The testing framework that comes with 1.8 (test/unit) is very limited and has far fewer features than RSpec. If we started Braintree today, would we use RSpec? I'm not sure.

You talk about the burden of learning RSpec to contribute to curator. We thought about the burden from the other side. We didn't want to rewrite all of our tests in order to open source the library. It's a lot of work to open source part of an existing application. Rewriting a good portion of the code means that we are less likely to do it.

In any case, I believe RSpec is fairly straight forward and similar to the spec syntax of MiniTest. I hope that it won't be be difficult to use, especially when you can follow existing patterns in the code. Furthermore, I hope that learning RSpec won't prevent you from contributing to curator. You might even decide that you like RSpec. 😄

@brandonweiss
Copy link
Contributor Author

For sure, I didn't mean to imply I didn't understand why you made the decisions you did or that they weren't the right ones at the time. The whole reason RSpec exists is that the current offerings at the time weren't good enough.

That said, continuing along a path solely because it correctly solved a problem a while ago that no longer exists is a smell. If you think that if you had to start the project over from this point, and that you would choose MiniTest instead of RSpec because it has the features you need and it's more common, and thus would engender more contributions, then it seems like it make sense to start moving in that direction.

I completely agree with everything you've said; they're the exact same conclusions I would have made, however, I think they're only the conclusions I would have made if I was thinking in the short-term. If I'm thinking long-term, I think switching to a simpler library that's more commonly used (and the current standard) would be overall a net positive.

Just out of curiosity, if I offered to switch the test framework to MiniTest, what would you say?

@brianewing
Copy link

Isn't RSpec just fine? It's still a predominant test library, and a big undertaking to rewrite the tests with something like MiniTest/spec (which is extremely similar to RSpec in any case) seems a bit unnecessary/potentially risky.

Practically, couldn't you familiarise yourself with RSpec faster than rewriting the entire specs? Or is there a practical benefit to the specs having a slightly different syntax?

@brandonweiss
Copy link
Contributor Author

The functional differences between RSpec and MiniTest are negligible—as you say, they're very similar, so that's not a reason to switch. Whether or not switching makes sense depends on what you're optimizing for. If you're optimizing for your subjective taste, or avoiding risk and unnecessary work in the short-term, switching from RSpec to MiniTest doesn't make any sense. However, if the point of open sourcing the project was to create a community and improve the library, then objectively switching to MiniTest probably does make more sense, for a few reasons:

  • RSpec is a third-party library. It's a dependency, and a heavyweight one at that. In most cases the less dependencies something has the better.
  • RSpec is the second biggest testing framework, not the first. A lot of people use it, but most do not. Most open source projects use MiniTest for consistency. More people can contribute to a project that uses MiniTest than RSpec.
  • Practically, it would be faster for me to familiarize myself with RSpec than rewrite the tests. But it's not more practical for multiple people to do so. It's far more efficient to take a day or two and switch the testing framework, than lose some large percentage of potential contributors because they're too busy to learn a testing framework that is slowly becoming irrelevant.
  • There's a lot to be said for perception. More than just the immediate barrier to entry of using a tool that not everyone knows, how a project is designed and what tools it uses says a lot to people about whether or not it's going to survive in the long-term. It's a bit of a chicken and the egg problem, but most people are only going to invest time in something if it seems like it has longevity.

@pgr0ss
Copy link
Contributor

pgr0ss commented Nov 1, 2012

In addition to what brianewing said, we still want to support ruby 1.8. So we do not want to switch to a 1.9 only testing framework.

@pgr0ss pgr0ss closed this as completed Nov 1, 2012
@brandonweiss
Copy link
Contributor Author

MiniTest is not 1.9 only; MiniTest works with 1.8 and 1.9.

@pgr0ss
Copy link
Contributor

pgr0ss commented Nov 1, 2012

MiniTest is a separate gem for 1.8, so it has the same dependency issue you mention above.

In any case, thanks for your input. It's been a good discussion, but we are not interested in switching test frameworks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants