When I’m evaluating any particular framework or technology I usually ask myself two questions:
1. How do I like the technical merits of this tool?
2. How would learning this tool help my marketability as a developer?
Let me give an example of an evaluation I did. Around 2011 I wanted to improve my front-end skills by learning a front-end framework. The big frameworks at the time were Ember, Backbone and Angular.
Of the three I figured Angular would become the most popular because it was backed by Google, so Angular is what I chose to invest time into learning. Time showed that my choice was right. (If I were performing the same evaluation today, it would probably be among Angular, Vue, and React. I’d definitely choose React.)
Sometimes the question “How would learning this tool help my marketability as a developer?” makes the question “How do I like the technical merits of this tool?” irrelevant. For example, I might enjoy coding in LOLCODE but I’m not going to spend my free time studying it to the exclusion of building some other, more marketable skill, like SQL.
When choosing a Rails testing framework you pretty much have three main options: RSpec, Test::Unit and MiniTest.
At the risk of sounding overly simplistic, my “strategy” for picking a testing framework was just to use the most popular one.
I’ve worked on dozens of commercial Rails projects over the course of my career. My recollection is that all but one of those projects used RSpec. That’s just an anecdote, not data, but I don’t think it’s mere chance that almost every commercial Rails project I’ve worked on has used RSpec.
For that reason, my advice for how to choose a Rails testing framework is: just use RSpec.
You might think that it’s a dangerous/dumb way of thinking to just choose the most popular thing whenever you’re faced with a decision. I wouldn’t disagree. So by all means, if you’re not comfortable with just picking RSpec, do some practice exercises with Test::Unit and MiniTest as well as RSpec and see how you like each.