So you’re a Ruby beginner. You put on your coding gloves, turn on your computer, get ready to write your first code. You run your first test and boom; you get your very first error message : a scary, lurking creature you’ve never seen before.
While they may seem absolutely terrifying at first, error messages track your progress and understanding them is a critical step in your upward progression to becoming a good programmer.
Test-Driven Development (TDD) is a method of tracking the progress of your code. Our goal as programmers using TDD is to turn all red errors (indicating that our code is not functioning as it is supposed to), into green (indicating that our code is doing what it’s supposed to). The ideal is to get all tests to run with as little code as possible.
As developers, we want to start with all our tests failing. If they were all green and running, there would be nothing for us to do. As we approach the errors, we read the first one, being the one all the way at the top, and use it as a blueprint for writing our code. Don’t forget, the beauty of programming is having a bunch of failing tests 99% of the time. Having 100% running tests indicates that we are done and must move on to the next task.
“Test-driven development, or TDD, is the practice of writing your tests firsts, then using those tests to guide you as you write your actual production code. This may sound crazy, but it turns out that it makes writing code much easier. It provides a clear workflow and next steps while you’re building…”
As a new developer, odds are you are not writing your own tests and that these these tests have been written by other developers. It is extremely important that developers writing these tests communicate most efficiently what the code is supposed to do. This is the standard for a career as a developer — writing code and tests that others can understand and therefore build on or debug.
Ruby’s way of implementing such tests is through RSpec, a form of Behavior Driven Development (BDD) that describes the behavior of the code and what it is expected to do. As a subcategory of TDD, BDD simplifies testing by turning the confusing terminology of TDD into simple language for all to understand.
Approaching error messages with the proper tools is key. With a few small steps, error messages can go from an indecipherable chunk of text to one of the most helpful tools you will utilize as a programmer.
These are the four steps I believe can help you overcome error messages with ease:
- First step is to read the error message. After reading the error, analyze the syntax and look for familiar key words.
- Once you’ve read it through, identify what type of error it is. Identifying the type of error will make it easier to debug, and more importantly — tell you what to google. Don’t forget, google is your best friend and will help you understand your error messages more quickly and efficiently.
Some common types of ruby errors include:
- NoMethod Error
- Syntax Error
- Type Error
- Name Error
- Argument Error
3. Next you want to break-down the message into the who, why and where.
TypeError: no implicit conversion of String into Integer
Who → Tells you what type of error. In this case — TypeError (Refer to the “I” in RIBB).
NameError: undefined local variable or method `foo' for main:Object
Why → Explains why you are getting the error. The NameError may appear because no method has been defined.
SyntaxError: (eval):1: syntax error, unexpected '=', expecting $end
Where → the ‘1’ tells you what line of your code is causing your error.
4. Last, but not least, breathe. While error messages may be an unfamiliar concept to you now, they will help you tremendously.
Don’t forget, when you run the RSpec and you have many error messages, it is critical that you read them top-down, as we do with Ruby. Once you debug the first line, all other errors can be assessed.
If you utilize these four steps, you will develop effective techniques for approaching error messages that will eventually become second-nature.