There’s much I cannot recall, my memory was never what it should’ve been. However, I do recall the day I stepped into an accounting class as a freshman in high school. And no, I didn’t have a say in it. If you went to Fort Hamilton High School, like me, you may be familiar with the f-ed up schedules we were assigned with. And if there was anything I took away from that accounting class, it wasn’t the T-charts, debits and credits, nor the teacher’s flowing hair — it was CYA, ‘Cover Your Ass.’ And if you have any experience in any cut-throat business or if you’re just a New Yorker you get where I’m coming from. But where is this going you ask? Tests.
Now, this may be a traumatic and demonic term for you — you may have had countless dark nights cramming for exams, and the nervous breakdowns right before and right after the exam, but tests are there for a reason. Whether or not they are necessary, beneficial, sufficient, effective, or well-written is another debate. This is why I shall refer to these “tests” as “checks” from hereafter. Many advocates argue you should be writing checks before you even start writing your code. Your code should then be reflective of your checks.
Now this may sound troublesome, and a complete and utter waste of your time and effort — because clearly you’re a much better programmer than I will ever be — but let’s break it down for a sec:
- You’re stating your objectives and defining your goals in deliberate steps effectively leading to a colorful image of the outline of your program and/or application.
- You’re writing checks where if it functions properly, should react in a certain and particular way providing targeted outputs and return values.
- The syntax is unbelievably easy, just like me.
Last but not least, you can ensure you’re meeting your deliverables, or at least you have evidence of your interpretation of the somewhat vague deliverable instructions — CYA.
I always thought sapphire and emerald were the superior gem, and maybe this has something to do with Pokemon, but maybe it doesn’t. Either way, Ruby is where my life is at day-in, and day-out. As a budding junior developer in the making at Flatiron, I work with Ruby on the daily. What else am I working with you may ask, and that would most definitely be RSpec.
“RSpec is a great tool in the behavior-driven development (BDD) process of writing human readable specifications that direct and validate the development of your application.”
More importantly, how does one go about writing an RSpec test?
Oh, but one simply does!
- require ‘rspec’ and the file you’re testing
2. define what you’ll check with a describe block
3. begin to explain what behaviours (shoutout to my friends across the pond) you want to check with another describe block
4. add color and the meaning of life to a specific check with an it block or use context
5. state your expectations of the results and return values of your code
I had heard Python is very simple to learn and that’s the main reason for colleges and universities double-down on it for students’ first language, but I only realized exactly why when I heard Avi, co-founder of the Flatiron School, break it down with the philosophies of Python, and why he advocates for Ruby — fundamentally there should be only one way to do something. He argues it limits programmers’ freedom in a sense and how it is less exciting and expressive as Ruby.
As such, there are multiple ways you can check your methods, code and return values:
As you can tell, I’m not as gifted in articulating my thoughts as I once was, if ever, so I shall without further ado present a magnificent and benevolent barrage of code snippets:
Let’s just take a moment and enjoy the following :)
