What Exactly Is RSpec?

When be­gin­ning to learn Ruby, I never came across RSpec in the list of buzzwords and ac­ronyms as­so­ci­ated with pro­gram­ming. With my first ex­pos­ure to RSpec and the concept of Test Driven De­vel­op­ment, I was a bit con­fused about what the pur­pose was. When writ­ing meth­ods, I as­sumed call­ing meth­ods gave all of the test­ing ne­ces­sary to know that your pro­gram works. RSpec, I’ve learned, goes bey­ond that.

Jason Ar­hart’s RSpec for Be­gin­ners present­a­tion for the Las Vegas Ruby Group givens a con­cise yet com­pre­hens­ive over­view of what the pur­pose of using RSpec tests is. The point that really stuck with me is the idea of “focus on the what be­fore the how”. One of the things I’m mak­ing a con­scious ef­fort to prac­tice while learn­ing to code is to slow down, think meth­od­ic­ally, and break down each ne­ces­sarly step. Writ­ing RSpec tests is one way to do this. In order to write an ef­fect­ive RSpec test, you must know first what you’re pro­gram needs to do. This must be done be­fore the how<.

An­other thing Jason fo­cuses on in his present­a­tion is how RSpec tests ac­count of ex­pec­ted be­ha­vior. We talk about this some­times in class, and it’s one thing I like to think about when pro­gram­ming: it’s im­port­ant to ac­count for all the things a user might do with your pro­gram. I like to think about these things while pro­gram­ming be­cause one of the most ex­cit­ing things about cod­ing for me is the idea of my products being used by oth­ers and how they use them; RSpec test­ing cre­ates a com­pre­hens­ive way of test­ing for all of those dif­fer­ent user pos­sib­il­it­ies.

Comments